Control of KML export of feature attributes

DC KelleyDC Kelley Global Mapper UserPosts: 76Trusted User
edited July 2011 in Technical Support
The user's manual states:
The Feature Descriptions section allows you to setup what is contained in the description for each feature in the generated file. You can choose to include only the feature description and links to any files associated with a feature, you can choose to add attributes to this, or you can choose to provide your own HTML text to use for the feature description. If you use the HTML text option, you can embed the values of attributes from the feature in the text by enclosing the attribute name in percent signs, like %ATTR_NAME%. In addition to the name of attributes, you can also specify <Feature Name>, <Feature Desc>, <Feature Type>, <Longitude>, or <Latitude> as the attribute name to get the feature display label, description, type name, point longitude, or point latitude embedded in the result. If you need to embed an actual percent sign in your result, simply use two percent signs consecutively as an escape sequence.

Is there an example of this used anywhere I can get pointed to?

My basic problem is when I added attributes I somewhat expected them to end up as independent elements in the xml (which is ideal to me) or as xml attributes append to the <description> tag in the "Microsoft style" of use. What I see is a sort of html-ish mark up on the content of the <description> (legally its all CDATA to XML) and I want to avoid writing a parse for this content (or even using a transformation if possible).

What options do I have? Sorry for flooding the board with my newbie posts a bit today.

Current output is typically like:
      <description><![CDATA[Unknown Line Type<BR><BR><B>LENGTH</B> 
= 29.624 m<BR><BR><B>BEARING</B> = 85.6422°<BR><BR><B>LaneType</B> 
= Ped Bike Lane<BR><BR><B>Width</B> = 2.15m<BR><BR><B>LaneId</B> 
= 0x21<BR><BR><B>ApproachGroup</B> = 1]]></description>
      <name><![CDATA[test bike lane #2]]></name>

Preferred would be:
<description>Ped Bike Lane</description>
<gmstuff>
   <LaneWidth> 2.15m </LaneWidth>
   <LaneId> 0x21 </LaneId>
   <ApproachGroup> 1 </ApproachGroup>
<gmstuff>
<name><![CDATA[test bike lane #2]]></name>  <!-- rest of XML to follow -->

Any idea how to break the single line up or any control over this?

Comments

  • global_mapperglobal_mapper Administrator Posts: 17,238
    edited July 2011
    You could use something like the following for your description custom HTML to get something easy to parse:

    LaneWidth=%LaneWidth%<br>
    LaneId=%LaneId%<br>
    ApproachGroup=%ApproachGroup%

    There isn't any way to make them actual separate XML elements as some XML parsers won't like those files if those tags aren't in the schema (Global Mapper wouldn't care).

    Let me know if I can be of further assistance.

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com
  • global_mapperglobal_mapper Administrator Posts: 17,238
    edited July 2011
    You could use something like the following for your description custom HTML to get something easy to parse:

    LaneWidth=%LaneWidth%<br>
    LaneId=%LaneId%<br>
    ApproachGroup=%ApproachGroup%

    There isn't any way to make them actual separate XML elements as some XML parsers won't like those files if those tags aren't in the schema (Global Mapper wouldn't care).

    Let me know if I can be of further assistance.

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com
  • DC KelleyDC Kelley Global Mapper User Posts: 76Trusted User
    edited July 2011
    Will give this a try and see how it looks.
    Y.... if those tags aren't in the schema (Global Mapper wouldn't care).
    Is there an adopted official schema for KML? I do not mind creating my own, but unless the "other guy" has access to it, he has to accept (not understand) any well formed content he finds. Hence my thought it could be added.

    On another tact to solve this, I am looking over the other export formats that GM supports and the open streets form is a lot cleaner. It defines all point used at first and then just calls them out for the feature with the additional user attributes added to the element <tag> as in.
      <way id="-1000027">
        <nd ref='-61'/>
        <nd ref='-62'/>
        <tag k="name" v="test bike lane #2"/>
        <tag k="LENGTH" v="29.624 m"/>
        <tag k="BEARING" v="85.6422°"/>
        <tag k="LaneType" v="Ped Bike Lane"/>
        <tag k="Width" v="2.15m"/>
        <tag k="LaneId" v="0x21"/>
        <tag k="ApproachGroup" v="1"/>
      </way>
    

    I can cope with that, but two other problems come up to ask you about.

    First, the lat-long precision is only 6 digits past the decimal point, can this be 'cured' with the registry trick I have seen elsewhere to get more digits? If so this may be the way to go.

    Second, Any way to add the file link, I suppose I can juts make a unique tag for that, right?
  • global_mapperglobal_mapper Administrator Posts: 17,238
    edited July 2011
    Google publishes the official KML schema, they are the original creators of that format for Google Earth.

    I would expect 10 decimal digits of precision for the lat/lon coordinates in OSM files, not 6. Is that not what you are seeing?

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com
  • DC KelleyDC Kelley Global Mapper User Posts: 76Trusted User
    edited July 2011
    Duh on me. The Open Geospatial Consortium adopted KML Rev 2.2 as and far as I know that remains the current std, but I did not know they actually came up with a schema, it can be downloaded at the below link:
    http://schemas.opengis.net/kml/2.2.0/ogckml22.xsd

    Aside and off topic: Not pick on what they did and do, but a lot of stds people (both US and elsewhere) found it a rather crude compromise and good for consumers and address matching but not what "traffic engineers" or "vehicle safety" people wanted in terms of very detailed lane by lane data for road network use. That being said it is likely another 5 years before we can get all the parties together to "fix/add' things to reflect what various world wide deployments are doing in a structured content way. I will generate an XMLSpy html documentation page for that schema over the weekend and post a link here. This type of documentation is graphical and makes browsing the relationships much easier. The element <description> is just an single occurrence (optional) open string with no restriction facets.

    On open streets....
    Regarding the OSM file. I just regenerated it and here are the two IDs mentioned in the scrap above.
    <node id='-61' lat='33.843112' lon='-112.134962'/>
    <node id='-62' lat='33.843132' lon='-112.134643'/>

    Still have 6 digits. Is my projection perhaps at fault here? If we can overcome that, I think I can make better use of that format for now.
  • global_mapperglobal_mapper Administrator Posts: 17,238
    edited July 2011
    Ah you are correct, while the <node> records for single point features had 10 decimals, those that form lines only had 6. I have updated those <node> records for lines to have 10 digits as well. I have placed a new build at http://www.globalmapper.com/global_mapper12.zip with the change for you to try. Simply download that file and extract the contents into your existing v12.xx installation folder to give it a try. If you are using the 64-bit v12 version there is a new build at http://www.globalmapper.com/global_mapper12_64bit.zip .

    Let me know if I can be of further assistance.

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com
  • DC KelleyDC Kelley Global Mapper User Posts: 76Trusted User
    edited July 2011
    I take it there is a formal schema for that as well, please post a link and I will do the XML SPy documentation on that as well.

    I am testing both paths now (SOM and KML formats), your trick to control the attribute exporting brings KML up to even again so its hard to choose. I am amazed at your ability to re-gen a client build so quickly based on these things. I will try it in a day or so but am loving what is there. I can hardly wait to mildly pick on a FHWA DOT person who is happy with their recent ESRI site license deal.

    Is there any way to force a line feed into a line like: LaneWidth=%LaneWidth%<br>
    When I try things like: LaneWidth="%LaneWidth%"\n
    I am getting the <br> tag still which is not a big deal but hard for the human to read.
    When I actually put a line feed in there, I get a blank space. A" \t" shows up as a literal (not a tab)
    Are these shell replacement rules documented somewhere?

    I probably need the quotes to contain the content when ill-formed until I have mastered the API, but if I can get a bit of "white space" to XML and semi-well formed view to a text editor, so much the better.
  • global_mapperglobal_mapper Administrator Posts: 17,238
    edited July 2011
    Do you mean the scheme for the OSM XML format? I would check www.openstreetmap.org for that one.

    There isn't really a way to force a line feed in the HTML description text, really you wouldn't normally directly read an XML file but would instead display it in an XML parser so you can see the nested structure, even something like Internet Explorer can do this with .xml files. There shouldn't be any literal (i.e. \n, \t) replacement from the special custom HTML text, are you seeing some?

    Thanks,

    Mike
    Global Mapper Support
    support@globalmapper.com
  • DC KelleyDC Kelley Global Mapper User Posts: 76Trusted User
    edited July 2011
    DC Kelley wrote: »
    ... Open Geospatial Consortium adopted KML Rev 2.2 as and far as I know that remains the current std, .... can be downloaded at the below link:
    http://schemas.opengis.net/kml/2.2.0/ogckml22.xsd
    ... I will generate an XMLSpy html documentation page for that schema over the weekend and post a link here.

    I started to do this and then found this link http://code.google.com/apis/kml/documentation/kmlreference.html
    Which is IMO much better, both styles allow you to click about in the object model expressed by the schema, which is was I wanted.

    By contrast the XML of Open Streets is more complex and does not lend itself to this as easily. Here is a link of you want a bit more http://wiki.openstreetmap.org/wiki/Database_schema

    I think from our needs here that the HTML that Mike has shown wil do the job until I can learn more about about the SDK.
  • DC KelleyDC Kelley Global Mapper User Posts: 76Trusted User
    edited July 2011
    Back into this problem after several days of other work tasks (my boss might call it real work) and the preferred solution is one of using KML with some output html replacement bits like:
    <add> <!-- Lane Info --> 
    <laneName>%LaneID%</laneName>  
    <laneNumberHex>%LaneID%</laneNumberHex>  
    <laneAttributes>%Attributes%</laneAttributes>  
    <laneWidthStart>%LaneWidth%</laneWidthStart>  
    <isInbound>%isInbound%</isInbound>
    </add>
    

    This gives an output like (the every last lines in a KML file):
        <Placemark>
          <description><![CDATA[
    <add> <!-- Lane Info --> 
    <laneName>0x21</laneName>  
    <laneNumberHex>0x21</laneNumberHex>  
    <laneAttributes></laneAttributes>  
    <laneWidthStart>2.15m</laneWidthStart>  
    <isInbound>test</isInbound>
    </add>]]></description>
          <name>Bike lane2 test</name>
          <styleUrl>#line9</styleUrl>
          <LineString>
            <coordinates>
              -112.1349548810,33.8431105584,0
              -112.1346357398,33.8431308513,0
            </coordinates>
          </LineString>
        </Placemark>
      </Folder>
    </Document>
    </kml>
    

    Works well for the need and leaves many options for more development latter. The above makes a good "fake" XML looking output (fake because it is all inside a string element called <description> one can parse). And FYI, the GM tool DOES add line feed if the replacements above are used i (but depending the XML editors you use you may not see them, try "NordPad" to see this with no xml re-flow going on).

    Thanks Mike, this opens a wide door.
Sign In or Register to comment.