[Requests] KML-2.2 suggestion

Sam Halliday sam.halliday at gmail.com
Thu Dec 27 10:27:46 EST 2007


Hello all,

I am the primary maintainer of the GPL project OpenLAPI.com which is  
an open source implementation of JSR-179 (the Location API for J2ME).  
For development purposes, we have a Keyhole Markup Language backend  
that allows developers to author a KML file describing a trail and  
then that is emulated in the development environment. At deployment, a  
GPS device is required (or some level of opt-in from network operators).

I understand that this is the correct place to raise comments  
regarding the proposed KML-2.2 standard. If I am mistaken, please do  
let me know.

My comment is regarding the "coordinates" element, which currently  
takes a comma-separated list of lon,lat[,alt]. In my opinion, this is  
inconsistent with the rest of the KML specification which has data  
nicely formatted into their respective elements... as XML promotes.

The disadvantage with "coordinates" being free flowing text is that it  
means that XML parsers cannot validate the contents and pushes  
validation (and additional parsing!) higher up into client code to  
check that the contents are correct. In my case, where the target  
platform is J2ME, this makes parsing code much more complicated and it  
actually contributes an additional 2K of bytecode to any resulting  
applications. That's a lot for a J2ME application.

I suggest that the "coordinates" element be updated to either hold a  
list of longitude, latitude and altitude ELEMENTS (instead of free  
text) or Location elements. This would greatly simplify the filetype  
for parsers.

As a solid example, consider the currently valid case (notice the  
ambiguity of the whitespace in the data, which has probably been  
mangled by my e-mail client anyway)
         <coordinates>
           -122.377830,37.830445,0
           -122.377576,37.830631,0
           -122.377840,37.830642,0
           -122.377830,37.830445,0
         </coordinates>

(167 bytes, 96 compressed) which could be rewritten

         <coordinates>
                 <longitude>-122.377830</longitude>
                 <latitude>37.830445</latitude>
                 <altitude>0</altitude>
                 <longitude>-122.377576</longitude>
                 <latitude>37.830631</latitude>
                 <altitude>0</altitude>
                 <longitude>-122.377840</longitude>
                 <latitude>37.830642</latitude>
                 <altitude>0</altitude>
                 <longitude>-122.377830</longitude>
                 <latitude>37.830445</latitude>
                 <altitude>0</altitude>
         </coordinates>

(413 bytes, 133 compressed) with the added advantages of content  
validation, no ambiguity in content ordering and more simplified  
parsing code that doesn't need to deal with whitespace, commas or  
validation outside of the XML parser.

Please let me know if this is a comment that you would be interested  
in discussing further.

-- 



Sam

http://fommil.me.uk
http://javablog.co.uk




More information about the Requests mailing list