MultiGeometry LineString issue (extra lines)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Link:
http://www.geocodezip.com/geoxml3_test/v3_geoxml3_kmltest_linktoB.html?lat=-33.9
19882&lng=151.037571&zoom=14&type=m&filename=http://www.geocodezip.com/geoxml3_t
est/3dgooglemodels_com_au_cbd_lap_a7_kml.xml

What is the expected output? What do you see instead?
Line with 2 arrowheads like this:
http://www.geocodezip.com/geoxml3_test/v3_geoxml3_kmltest_linktoB.html?lat=-33.9
19882&lng=151.037571&zoom=14&type=m&filename=http://www.geocodezip.com/geoxml3_t
est/3dgooglemodels_com_au_cbd_lap_a7a_kml.xml

geoxml3 combines multiple linestrings into a polyline by concatenating them 
together.  Does not work if the end of one is not the beginning of the next.

Workaround: Define the LineStrings so each line is continuous from start to end 
(may require adding additional points like the example above, or break them 
into separate lines)

Original issue reported on code.google.com by geocodezip on 7 Mar 2011 at 12:37

[GoogleCodeExporter]

I'm still seeing this issue, over larger areas, seems polygons are being 
generated instead of point to point polylines is there something we can pass to 
the parser to ignore this?

Original comment by themojow...@gmail.com on 16 May 2013 at 9:49

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

This is not fixed. There is a workaround and hasn't been a lot of interest.

Original comment by geocodezip on 16 May 2013 at 12:43

[GoogleCodeExporter]

Can you provide an example where you are seeing this and it is a problem?

Original comment by geocodezip on 16 May 2013 at 1:13

[GoogleCodeExporter]

This is a problem whenever LineStrings that are not simply point-to-point, but 
for example of a trunk-and-branch architecture. For instance, the following 
google maps kml-sample doesn't draw properly with geoxml3; and there is no 
workaround.

http://code.google.com/p/kml-samples/source/browse/trunk/kml/MultiGeometry/multi
-linestrings.kml

Original comment by jsyeom...@gmail.com on 3 Jun 2013 at 6:13

[GoogleCodeExporter]

> This is a problem whenever LineStrings that are not simply point-to-point, 
but for 
> example of a trunk-and-branch architecture

That is true.  

> there is no workaround.

The work around is to make the lines point-to-point.  Is there a use case that 
requires geoxml3 where that can't be done?

http://www.geocodezip.com/v3_GoogleEx_layer-kml_linktoB.html?filename=http://www
.geocodezip.com/geoxml3_test/multi-linestrings.kml

http://www.geocodezip.com/geoxml3_test/v3_geoxml3_kmltest_linktoB.html??type=m&f
ilename=http://www.geocodezip.com/geoxml3_test/multi-linestrings.kml

With workaround:
http://www.geocodezip.com/geoxml3_test/v3_geoxml3_kmltest_linktoB.html??type=m&f
ilename=http://www.geocodezip.com/geoxml3_test/multi-linestrings_workAround.kml

Original comment by geocodezip on 3 Jun 2013 at 10:10

[GoogleCodeExporter]

We have 100s of .kml files to display on the map. Each .kml file contains 100s 
of LineStrings that each contain 10-100 coordinates. Additionally, these 
LineStrings are disjointed pieces of a trunk-and-branch architecture. These 
.kml files are obtained from an external source that we can't control, and the 
pre-processing you are suggesting as a workaround would be nearly impossible 
based on the size of our data set.

Original comment by jsyeom...@gmail.com on 4 Jun 2013 at 1:24

[GoogleCodeExporter]

That makes sense.  Why do you need to use geoxml3 in your use case? KmlLayer or 
FusionTablesLayer would overlay those on a map, why do you need geoxml3?

I can start looking at addressing this, the reason I haven't seriously looked 
at it is that it may impact performance and will probably add complexity.

Patches are welcome if you have a suggested fix.

Original comment by geocodezip on 4 Jun 2013 at 1:36

• Added labels: Priority-Medium
• Removed labels: Priority-Low

[GoogleCodeExporter]

I apologize in advance for my lack of knowledge/experience with maps, and thank 
you for the great work you do with geoxml3. I was using geoxml3 because these 
.kml files are government classified and I can't expose them to the open 
internet. I thought geoxml3 was the only way to parse locally behind our 
firewall, since KmlLayer requires google to access the .kml files.

Original comment by jsyeom...@gmail.com on 4 Jun 2013 at 2:03

[GoogleCodeExporter]

Another option would be geoxml-v3 

http://code.google.com/p/geoxml-v3/

Lance Dyas' version of the parser, I don't use that much, and not sure how 
actively he is supporting it, but if it works for you, that is another option

Original comment by geocodezip on 4 Jun 2013 at 5:57

[GoogleCodeExporter]

Potential fix (not checked in, local copy for now):
http://www.geocodezip.com/geoxml3_test/v3_geoxml3_kml_linestring_test_linktoB.ht
ml??type=m&filename=http://www.geocodezip.com/geoxml3_test/multi-linestrings.kml

if you could test and provide feedback on any issues you see in your 
application.

Original comment by geocodezip on 7 Jun 2013 at 6:41

[GoogleCodeExporter]

Original problematic KML
http://www.geocodezip.com/geoxml3_test/v3_geoxml3_kml_linestring_test_linktoB.ht
ml?lat=-33.919882&lng=151.037571&zoom=14&type=m&filename=http://www.geocodezip.c
om/geoxml3_test/3dgooglemodels_com_au_cbd_lap_a7_kml.xml

Original comment by geocodezip on 7 Jun 2013 at 6:56

[GoogleCodeExporter]

I tested using my .kml and your geoxml3_linestringFix.js, and it worked/looked 
great. Thank you so much for the great solution. We really appreciate it.

Original comment by jsyeom...@gmail.com on 7 Jun 2013 at 1:40

[GoogleCodeExporter]

I am still testing.  Please update this issue if you see any issues.  If there 
are no issues this version will be checked in at some point.

Original comment by geocodezip on 7 Jun 2013 at 2:02

• Changed state: Started

[GoogleCodeExporter]

Committed change revision 103.  Please update this issue with any problems you 
see with the fix.

Original comment by geocodezip on 8 Jun 2013 at 5:45

• Changed state: Fixed