Solution for diminishing placemarks when close to ground?

827 views
Skip to first unread message

barryhunter (KML Guru)

unread,
Apr 25, 2009, 6:46:53 PM4/25/09
to KML Developer Support - Advanced Support for KML
in Google Earth as you get closer to ground distant placemarks get
smaller and disappear.

Is there any solution to prevent this from happening?

I've made the suggestion to use regions, so can replace the placemark
with one with a really big scale icon/label. This works, but to work
well, is going to need many versions of the placemark to give the
impression of a almost constant size.

This is to make a toposcope style file, that labels distant peaks.

There is a sort of demonstrator here:
http://www.nearby.org.uk/google/temp/ScalingCadair.kml
this uses two sizes.

Start at the initial view, which shows a reasonable size icon, then
descend onto a peak in the foreground - the icon switches again to
reasonable size. But descend into a valley and again gets too small


- It also includes a line sting to visualise the size of the 'region'
used for swapping the placemarks.





Roman N

unread,
May 6, 2009, 12:52:47 PM5/6/09
to KML Developer Support - Advanced Support for KML
Hi Barry,

Any luck with this? I haven't been able to find a non-hacky (read: non-
region-based) method of controlling icon sizes at varying camera
distances. This may be a limitation of KML that we should file as a
feature request in the issue tracker.

Oh, and, there's always the plugin/API :)

Thanks,
Roman

barryhunter

unread,
May 6, 2009, 1:29:52 PM5/6/09
to KML Developer Support - Advanced Support for KML
I got a partial solution working using a VBR to <Update> the <scale>
in the style tag.

The main issue is determining what GE uses to decide on the
'shrinking' of the main labels. (because need the <scale> to reverse
its effect)

- mainly it seems to be altitude, and seems to be altitude above
terrain. So used cameraAlt, and a webservice to get the altitude at
that point, and worked out a non-linear function to deduce a scale.

As I say it worked, but was very jumpy (due to the delay of the VBR) -
but mainly its fickle, it works in some locations, not in others...


Thought of the Plugin - but that suffers the same issue, - need to
know the function to apply to 'scale' to counteract the built in
strinkage.

Barry Hunter

unread,
Jun 24, 2009, 7:52:38 AM6/24/09
to KML Developer Support - Advanced Support for KML
A potential 'solution' here:
http://groups.google.com/group/google-earth-browser-plugin/browse_thread/thread/ec40f6f0a29075e8/74c593ec33952b3b?show_docid=74c593ec33952b3b

use a Model rather than the default icon!

Obvious when think about it.

Barry Hunter

unread,
Jun 24, 2009, 7:57:23 AM6/24/09
to KML Developer Support - Advanced Support for KML
Of course that works for the 'icon' but not the label.

Maybe could make a script that creates dynamic text as a .dae file? Of
course wouldnt rotate to face the user tho :(

On Jun 24, 12:52 pm, Barry Hunter wrote:
> A potential 'solution' here:http://groups.google.com/group/google-earth-browser-plugin/browse_thr...

Barry Hunter

unread,
Jun 24, 2009, 8:16:19 AM6/24/09
to KML Developer Support - Advanced Support for KML
Any ideas what form the feature request should take? At the moment
thinking adding a <Lod> style param to <IconStyle> and <LabelStyle>

Effectivly have a ramping down curve for icons. Same size regardless
until get close to ground then deminish. Labels have a similar method,
but they also disappear totally at high altitude.

The <Lod> format would be borrowed from <Regions>, but the scaling
values would actully scale the icon/label, based on the projected size
of a none scaled icon/label.

icons could either use a fixed 32x32 area say, or use the actual size
of the image. Not so sure for label, maybe use a fixed size, or use
the actual size of the label (which would mean longer labels would be
hidden quicker)

This would allow great flexibility, but also allow a 'fixed' scale to
be assertained but overriding the default.


I probably havent explained it that well, will see if can come up with
a demo based on the plugin. (possibly not scaling an actual placemark
as that not easily done - due to the inbuilt scaling interferring with
it!)

Roman N

unread,
Jun 25, 2009, 2:50:23 PM6/25/09
to KML Developer Support - Advanced Support for KML
Hey Barry,

I don't think <Lod> would make sense in this case because it requires
some mapping from a 3D physical (geo) volume --> pixel size ... since
icons and labels don't occupy any physical volume, it doesn't seem to
work here.

If you're simply trying to prevent altitude/camera distance-based
scaling, how about something like:

<IconStyle>
<gx:cameraScale>0</gx:cameraScale>
..
</IconStyle>

and the same for <LabelStyle> ? If you think there's a more
fundamental feature request here, then let's brainstorm on that. But
this seems simple, both from a KML and implementation point of view.

Thanks,
Roman

Barry Hunter

unread,
Jun 25, 2009, 3:39:25 PM6/25/09
to KML Developer Support - Advanced Support for KML
Not thinking exactly <Lod>, just mimiking the way it has *both* a max
and min - and specifies 'fade extents'

being able to turn off the scaling is the most basic requirement,

But while working on this, it would make sence to incorperate as much
flextbility as possible, and being able to specfiy the fade for both
ends would be very useful.

For example people often complain that when zoomed out the icons look
way too big (and the use regions to create a duplicate set with
smaller icons) - if could make the icon strink at high altitude it
would furful this criteria as well :)
(with the bonus it would fail far more gracefully on other clients
(that dont support regions), the fading info would simply be ignored)

Roman N

unread,
Jun 26, 2009, 6:27:02 PM6/26/09
to KML Developer Support - Advanced Support for KML
Ah, I see what you're saying. So maybe something like <IconStyle>/
<minScale> and <maxScale> with some sort of ramp function? Though, how
would the ramp be determined... left up to the KML implementer, or
explicitly defined? And, then again, based on what parameters--
altitude, distance, etc.

Great discussion so far!

Roman
Reply all
Reply to author
Forward
0 new messages