Closed GoogleCodeExporter closed 9 years ago
Original comment by geocodezip
on 13 Dec 2011 at 2:19
fixed revision 63
changed submitted fix slightly to handle case when no <scale> tag present.
Test case:
http://www.geocodezip.com/geoxml3_test/v3_geoxml3_kmltest_linktoB.html?filename=
http://www.geocodezip.com/geoxml3_test/councilsites_co_uk_carparks_scale_kml.xml
Original comment by geocodezip
on 26 Dec 2011 at 5:24
I don't think this fully working yet. One issue is the shadow size is still
32x32, so there is an invisible click target behind smaller markers. This
occurs even if you pass in a shadow icon that is smaller than 32x32 (ie, the
shadow image still gets stretched).
Click in an area right above a marker in this example:
http://www.yourmapper.com/demo/geoxml3test.htm?filename=http://www.yourmapper.co
m/api/markers.php?id=27ba9966d150bfe9831c73e2735dd008239845e1&num=10&lat=38.2385
75&lon=-85.715599&f=kml&egeo=1
Original comment by schnue...@gmail.com
on 27 Jan 2012 at 5:04
The _scaling_ of markers is working. This has to do with the click target (you
are probably correct that the shadow is wrong though). If you specify a
"shape" property for your custom markers (like you did the "shadow" property):
markerOptions: {shadow: "http://static.yourmapper.com/marker/tran-13.png"}
you should be able to fix it.
Original comment by geocodezip
on 28 Jan 2012 at 3:27
And if you put the <scale> tag in your icon definitions, it seems to work.
http://www.geocodezip.com/geoxml3_test/www_yourmapper_com_api_markers_markerclic
k.html
Original comment by geocodezip
on 28 Jan 2012 at 4:22
[deleted comment]
As a complete aside, I really appreciate the example in
http://code.google.com/p/geoxml3/issues/detail?id=44#c5 (comment 5) I didn't
know you could make shadow a markerOption to specify a shadow image. This
allows me to specify an empty string for the option (our KML does not a shadow
image for the custom markers). It thus avoids a huge string of 404s from the
browser attempting to load the constructed by geoxml3 shadow file URL.
Original comment by fami...@gmail.com
on 30 Jan 2012 at 7:45
Original issue reported on code.google.com by
verm...@nurc.nato.int
on 13 Dec 2011 at 11:19Attachments: