irenadorfman / geoxml3

Automatically exported from code.google.com/p/geoxml3
0 stars 0 forks source link

Mega patch for various items #53

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
This patch covers about 3 solid weeks of work getting some of the other 
features implement for my needs.  Maintaining KML standards and making sure 
everything was open-ended was priority over merely jury-rigging it to make it 
only suit my requests.

This patch implements the following:

* KMZ support with full support for inline images (though with some limitations 
in IE)
* Auto-loading of KML/Z files that are dependencies via styleUrl tags
* Full support for the following style tags:
  * BalloonStyle (bgColor, textColor, text, displayMode)
  * IconStyle (href, scale, hotSpot, gx:x/y/w/h)
  * LineStyle (color, colorMode, width)
  * PolyStyle (color, colorMode, outline, fill)
* Full support for styleMaps, including external references
* Proper defaults of styles, per KML 2.2 standards
* Proper implementation of colorMode=random in styles
* Support for visibility and gx:BalloonVisibility tags within Placemarks
* Support for ExtendedData tag set and description substitution using those 
variables
* Support for icon palettes and correct icon sizes
* Logging of XML parse errors
* Some tab/spacing refactoring (so, some of the patch add/removals are just 
space adjustments)

This should fix Issue #s: 14, 28, 47, 48, 49.

I apologize for the size and scope of this patch, but I'm willing to explain 
any code points you have questions with.

Original issue reported on code.google.com by sineswi...@gmail.com on 14 Feb 2012 at 9:52

Attachments:

GoogleCodeExporter commented 9 years ago
you wrote:
> Sent you an email with details.

Thank you.

You are using the "development/nightly" version of the v3 API:
<script type="text/javascript" 
src="http://maps.google.com/maps/api/js?sensor=false">

I think it is related to this issue:
http://code.google.com/p/gmaps-api-issues/issues/detail?id=3908

It works if you change that to v=3.6 (the "Frozen" version):
http://code.google.com/apis/maps/documentation/javascript/basics.html#Versioning

<script type="text/javascript" 
src="http://maps.google.com/maps/api/js?sensor=false&v=3.6">

I will look at addressing it, it seems to be an issue with the canvas 
implementation of markers.  I was hoping that it would be fixed by google.

Do you mind if I post an example using your kml from my domain?

Original comment by geocodezip on 13 Mar 2012 at 11:08

GoogleCodeExporter commented 9 years ago
Example with a KML generated from this testmap is fine:

http://maps.google.com.au/maps/ms?msid=213454297081242566384.0004a6be375594f4734
0d&msa=0&ll=-37.814429,144.970908&spn=0.030343,0.066047

The url to the kml would be:

http://maps.google.com.au/maps/ms?msid=213454297081242566384.0004a6be375594f4734
0d&msa=0&output=kml

Today I bumped into another issue but that may have to do with me blindly 
assuming general functionality between the polys and kmz branch was unchanged.

I generate a list on the sidebar with links to the markers - ( similar to 
http://www.geocodezip.com/v3_MW_example_map2.html )

The links seem to be "randomized" tho, as far as I can see upon first load 
perhaps. Reload fixes the ordering - so that may be due to a bit naive coding 
on my part - but it worked flawlessly with the polys branch sofar. This is 
reproducible with the "accommodations map" that I linked in my email.

Original comment by sylvia.s...@gmail.com on 14 Mar 2012 at 4:22

GoogleCodeExporter commented 9 years ago
@geocodezip@gmail.com:
And you are spot on re the disappearing markers problem. It is indeed directly 
related to that issue. I will relink my script so it will use the frozen 
version (what it should have been to start with). Thank you for that bit of 
information!

Original comment by sylvia.s...@gmail.com on 14 Mar 2012 at 4:38

GoogleCodeExporter commented 9 years ago
I created issue 55 to track the markers issue in the polys branch.

Original comment by geocodezip on 14 Mar 2012 at 6:49

GoogleCodeExporter commented 9 years ago
Maybe I'm missing something but seems to me that palette support for markers is 
broken. 

icon.dim.x and icon.dim.y are set to the values of gx:x and gx:y in the icon 
element, they are then multiplied by scale and used to create the origin point 
for the marker image. BUT -
The kml spec says x and y are from the LOWER left 
(https://developers.google.com/kml/documentation/kmlreference#gxx)
but the maps API says the origin point is from the UPPER left 
(https://developers.google.com/maps/documentation/javascript/reference#MarkerIma
ge)

Took me way too long to figure out why I was seeing nothing (my sprite is only 
partially done and the upper "rows" are blank!)

Am I missing something obvious???

Original comment by slubow...@gmail.com on 21 Mar 2012 at 10:54

GoogleCodeExporter commented 9 years ago
Do you have an example that you can share?
Probably create a new issue would be best, with a link or attach
something that can be used to reproduce the issue.  There currently
aren't any test cases using sprites.

Original comment by geocodezip on 22 Mar 2012 at 1:00

GoogleCodeExporter commented 9 years ago
OK, created issue 56 to cover the problem described in comment 55

Original comment by slubow...@gmail.com on 22 Mar 2012 at 3:18

GoogleCodeExporter commented 9 years ago
See issue 56 which addresses another style problem - partial inline style 
(balloon) overwrites icon style applied by styleUrl

Original comment by slubow...@gmail.com on 22 Mar 2012 at 2:40

GoogleCodeExporter commented 9 years ago
Re: #55

Lower-left?  Seriously?  Sometimes I think the KML standard is "broken".  

This may mean that the image WxH needs to be known no matter what.

Original comment by sineswi...@gmail.com on 22 Mar 2012 at 5:07

GoogleCodeExporter commented 9 years ago
Closing.  All issues discussed here are covered by other issues.  Please open 
new issues for any problems discovered.

Original comment by geocodezip on 19 May 2012 at 8:19