Closed GoogleCodeExporter closed 9 years ago
Sorry - one point I did not mention is I am loading a KML file...
Original comment by fahrenhorstw
on 30 Dec 2013 at 1:38
Update: Fixed that issue by re-ordering the objests... Instead of instantiating
the KmlObject by pointing to the kmlDocument.parseFile, I instantiated a new
instance then applied the KmlObject.POLYGON setting to mObjectType and then
pointed it to the kmlDocument.parseFile();
But now it is complaining about the polygonOverlay.setStrokeWidth (line 297,
KmlObject.java). I am sure I am missing a step somewhere... The following is my
code:
<pre>
KmlObject kmlObject = new KmlObject();
kmlObject.mObjectType = KmlObject.POLYGON;
KmlDocument kmlDocument = new KmlDocument();
kmlObject = kmlDocument.parseFile(file);
Drawable defaultMarker = getResources().getDrawable(R.drawable.flag_green);
FolderOverlay province = (FolderOverlay)
kmlDocument.kmlRoot.buildOverlays(this, mapView, defaultMarker, kmlDocument,
false);
mapView.getOverlays().add(province);
</pre>
Perhaps you could point me in the right direction?
Thanks.
Original comment by fahrenhorstw
on 30 Dec 2013 at 2:18
I see nothing wrong in your code.
The behaviour you describe is strange, because the very first action of the
KmlSaxHandler is to instantiate the mKmlRoot as a new KmlObject.
Maybe the issue is linked to the content of the KML file you try to load.
Can you attach this file to the issue?
Just 3 remarks on your code:
1/ The KmlObject you created is replaced by the KmlObject returned by
parseFile. So the 2 first lines cannot be of any use:
KmlObject kmlObject = new KmlObject();
kmlObject.mObjectType = KmlObject.POLYGON;
2/ You can build KmlObjects yourself. But in this case, have a close look at
KmlObject class (members, and existing methods). Just changing the object type
(kmlObject.mObjectType = KmlObject.POLYGON;) is usually not sufficient to have
a valid object.
3/ Check the result of parseFile:
kmlObject = kmlDocument.parseFile(file);
if (kmlObject == null) {
//then there was an error when reading/parsing the file:
handle the error....
}
Original comment by mathieu....@gmail.com
on 30 Dec 2013 at 3:35
Hi
Thank you for your comments. Initially I did it the way you have it in the
tutorial (3), but then that gave errors. So I investigated and found that the
object type was not set which is why I manually set it.
I have also checked the kmlObject which is not null and is a valid object.
I have also thought that there was something wrong with the KML file so I
opened it up in ArcGIS which showed it correctly. But I also went through the
structure (http://www.opengeospatial.org/standards/kml) and discovered the the
line width was not set, so I put in the line width but then it still crashed
with a NullPointerException on line 297 of KmlObject.java (same place as before
but the line width was set this time and not null).
I am going to trace through the creation of the KmlObject and get back to you.
Best regards,
Original comment by fahrenhorstw
on 31 Dec 2013 at 5:10
Hi
The error is in the KML file format that the code is not expecting. Attached
there are 2 files: Province_test.kml is the original file and Province.kml is
the new file using an example structure from
http://www.opengeospatial.org/standards/kml (Best Practice) and it works.
If one compares the files, the original has an extra layer called Folder, which
is a valid tag, but not within the Document tag.
It may be a good idea to handle this? I got the original file from a publicly
available site.
Thank you for your help.
Best regards
Original comment by fahrenhorstw
on 31 Dec 2013 at 6:19
Attachments:
OK, I got it: it was in KmlObject.buildOverlays, for the POLYGON, the way mName
and mDescription were tested. As mName was null, mName.equals("") was causing
this NullPointerException.
I see that you use inline Style in Province.kml. It was not properly supported,
so I also fixed that.
Changes are now commited. I still have to upload the jar.
Original comment by mathieu....@gmail.com
on 31 Dec 2013 at 11:28
jar is now commited (v4.2.3).
Original comment by mathieu....@gmail.com
on 31 Dec 2013 at 12:36
Investigating on your sample file, it also appeared that the parsing was really
not efficient.
I just commited an improved version, which is approximately 10 times faster.
Original comment by mathieu....@gmail.com
on 1 Jan 2014 at 7:06
Happy New Year!!
Great - thank you!! Is that change in v4.2.3?
Original comment by fahrenhorstw
on 2 Jan 2014 at 5:09
No. It is commited at source level, and it will be in jar v4.2.4 (planned for
this week-end).
Original comment by mathieu....@gmail.com
on 2 Jan 2014 at 4:56
v4.2.4 commited.
Original comment by mathieu....@gmail.com
on 4 Jan 2014 at 11:29
Original issue reported on code.google.com by
fahrenhorstw
on 30 Dec 2013 at 1:36