KML icons misalign with hotSpot nodes

[rdewit]

KML Icons with hotSpot settings misalign. This is because the offset is not calculated properly. Thanks to Lance Dyas for reporting this issue.

The attached patch properly calculates the offset for hotSpot nodes. Please note that offset units in 'pixels' only work correctly when the image size is 32x32 pixels *or* when a width <w> and/or height <h> are defined in the Icon node (deprecated in KML 2.2beta). In all other cases, please use 'fraction' as units. This is because OL cannot automatically determine the size of the icon.

Bonus improvements:

• implemented 'scale' node parsing
• fixed a typo in the inline style handling

Works in both FF2 and IE6 and tests pass

[rdewit]

Fixed bug in y offset (fractions) + added 'magic' to 'know' that certain URLs are 64x64 pixels (maps.google.com/mapfiles/kml).

[rdewit]

There was a small bug in the y offset for fractions hotspots (fixed). Also added a clause where urls that start with maps.google.com/mapfiles/kml, the icon size is 64x64. Seems to work in most cases, but feels a bit hacky.

Please review patch kml_styling_hotspots_v2.diff

[crschmidt]

The only hacky problem I have with the google URLs (since your logic seems correct) is that we have to multiply the scale by .5, but that seems to be what Google Maps does, so that's not your problem, it's Google's/KML's.

I have a problem here though: in most places, you've multiplied 'x' by scale, but x is a string, not a number, since you don't ever call parseFloat/int on it, do you? Is that okay? In fact, I'm not even sure that you should be multiplying y times scale: the scale is for the size of the icon (which should be used for calculating height/width), *not* scaling the offset, especially not in the pixels case...

I also think that some of your calculations may be wrong. In our scheme, a negative offsetHeight pushes the image up the page. This means that in order to get the bottom, left 0,0 coordinates that KML wants, we have to have our offsetHeight be the *negative* of our graphic height by default. IT looks like this is *not* the case when yUnits is 'fraction'. In my code, I implement this with:

 style["graphicHeight"] * (parseFloat(y)-1.0);

I think you need the same here.

All the others are correct.

[crschmidt]

My comments on scale are wrong: multiplying by it is right (but I still think we need to parseFloat on x/y before we do).

[rdewit]

Thanx for your input crschmidt. Patch v3 should fix the issues that you mentioned: - parseFloat before doing any calculations - yunit fractions were wrong

Please review this one.

[crschmidt]

I commented on this on IRC, but not here:

Since we're calling parse* on all of these, we should centralize, and just call parseFloat on the x/y when we extract them, rather than separately in each if block.

[rdewit]

Replying to crschmidt:

I commented on this on IRC, but not here: Since we're calling parse* on all of these, we should centralize, and just call parseFloat on the x/y when we extract them, rather than separately in each if block.

I replied on this on IRC, but not here: ;-)

Does patch v3 not fix this (this is a new v3, I overwrote the old one)?

[crschmidt]

Indeed! Thanks. I'm going to commit this now.

[crschmidt]

(In [6494]) Apply patch from rdewit to fix parsing of hotSpot values on Icon objects in KML styles. This fixes issues reported with the location of icons when using KML styling. r=me (Closes #1426)

[rdewit]

As crschmidt reported on IRC: this fix breaks KML in IE6/7. I will look into it today and provide a new patch.

[crschmidt]

I think htis is probably just a sideeffect of #1428, not related to your work.

[crschmidt]

I'm reasonably certain this was just a side effect of #1428. IF we could check  http://dev.openlayers.org/sandbox/euzuro/pop/examples/sundials.html in IE6 / IE7 , and you see sun icons, that means this bug can be closed.

[crschmidt]

I've confirmed that this works in IE7 now. I think this means that this is fixed; closing pending any further reports of the issue.