KLM Parser / Renderer

[bratliff]

Any plans to split the KML parsing & rendering services ? It was a
welcome change from V2 to V3 for the directions service. Your "gx" or
"sf" services already do it. It enables changing the attributes of
individual components of the KML file.

Also, an off-line KML to JSONP conversion utility could be useful.

[Ben Appleton]

No plans at this point.  How would JSON would be any more useful than raw KML?  Afterall you can load the KML directly into the browser, parsing and modifying it as you wish.  What JSON schema would we use?

--
You received this message because you are subscribed to the Google Groups "Google Maps JavaScript API v3" group.
To post to this group, send email to google-map...@googlegroups.com.
To unsubscribe from this group, send email to google-maps-js-a...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-maps-js-api-v3?hl=en.

[William]

On Jul 14, 10:13 am, Ben Appleton <apple...@google.com> wrote:
>  What JSON schema would we use?

the one mentioned on page 38 of this Maps Data API talk?

http://dl.google.com/googleio/2010/geo-unleash-map-data-cloud-computing-geospatial-apps.pdf

[Ben Appleton]

Will it preserve every feature of the original KML?  (This is hypothetical: I don't work on it, I don't know).  Then we get into a classic API design problem - fast vs useful:

• If a user needs a specific feature of the original KML (say, the ordering of the Style tags relative to the Placemarks) that is not preserved in the JSON, that user is forced to fall back to parsing KML for themselves.
• If the JSON format drops too many such features, it sheds users.
• So the JSON format tries to preserve all, or almost all, of the original KML intact.
• Now the JSON format is no faster or better than loading KML directly.  Why would anyone use the JSON service?

If we were to launch such a service, we'd want it to be useful so that it's used.  Things that might make it useful:

• If the JSON is much more compact than KML, we can beat raw KML on latency.  This means distilling the KML to a subset that is useful for 90% of users: maybe we inline styles and network links, collapse folders, etc.  Maybe we also simplify and encode geometry.
• If the JSON allows you to read KMZ files, that's a plus.  But if that were the only win we could launch an unzip service which would be more generally useful.

But such a service could never beat a "roll your own" solution.  If you're designing for 1 application you can optimize for that application: dropping fields you don't need, simplifying geometry to the precision you need, deciding for yourself whether to follow network links, load Regions, inline images or not, and so on.

Finally, note we'd want to think carefully before allowing sites to fetch KML cross-domain, since this punches a hole in the browser same-domain security model.  Rendering it on a map is benign but fetching the raw data might be iffy.

I'm interested to hear what you'd use this for, since that helps us prioritize such requests.

- Ben

--

[bratliff]

On Jul 14, 12:13 am, Ben Appleton <apple...@google.com> wrote:
> No plans at this point. How would JSON would be any more useful than raw
> KML? Afterall you can load the KML directly into the browser, parsing and
> modifying it as you wish. What JSON schema would we use?

It would eliminate the proxy requirement. JSON is a much more compact
format than KML / XML. It is directly executable. It does not
require a separate parsing step. Extraneous elements could be
ignored. The reasons are similar to the reasons to split the
direction service. If I could legally use your "gx" or "sf" service
today, I would. The two services seem to be identical.

[Garthan]

On Jul 14, 6:15 am, bratliff <bratl...@umich.edu> wrote:
> On Jul 14, 12:13 am, Ben Appleton <apple...@google.com> wrote:
>
> > No plans at this point.  How would JSON would be any more useful than raw
> > KML?  Afterall you can load the KML directly into the browser, parsing and
> > modifying it as you wish.  What JSON schema would we use?
>
> It would eliminate the proxy requirement.

And that is a pretty direct boon I have a basic php proxy that I let
people snag
associated with my geoxml parser but its a pain for plenty of folk.

 JSON is a much more compact
> format than KML / XML.  

well not alot more compact intrinsically but it generally is a little
more compact even without too much work (the tag sizes are smaller but
they normally compress well due to duplication so the size gain is
smaller sometimes than it might seem .... but yes it is real.

It is directly executable.  It does not
> require a separate parsing step.  

Good particularly on that old dog IE whose xml parsing and handling
sucks.

Extraneous elements could be
> ignored.

I like json to contain the folder information too and for me the
structure
of the kml isn't extraneous it conveys meaning about the data... its
one feature
kml has over GML in fact the groupings of things can be very
significant

In general I agree lots of great features and most are the normal ones
associated with JSON

[Chad Killingsworth]

I have an XSLT file that will convert generic XML to JSON according to
the specs at http://code.google.com/apis/gdata/docs/json.html - you
only need to specify which elements can occur more than once in the
file. It also handles JSON-IN-SCRIPT with a callback parameter.

This would work great for KML - but would fail on KMZ.

Using something like this, it's pretty easy for the KML owner to
provide the JSON feed natively. If you'd like it, I'll post it
publicly. I use it in a variety of projects.

Chad Killingsworth

[Ben Appleton]

As Chad and others point out, anyone (not just Google) can launch a service to convert XML to JSON, proxy cross-domain requests, or unzip KMZ to KML. I think Google should focus on things only Google can do: providing fast and reliable access to geographic data such as tiles, geocodes, directions, and so on.

[bratliff]

On Jul 14, 11:45 pm, Ben Appleton <apple...@google.com> wrote:
> As Chad and others point out, anyone (not just Google) can launch a service
> to convert XML to JSON, proxy cross-domain requests, or unzip KMZ to KML. I
> think Google should focus on things only Google can do: providing fast and
> reliable access to geographic data such as tiles, geocodes, directions, and
> so on.

I would be satisfied with LEGAL access to your "gx" / "sf" service
without a key required.

[bratliff]

A third party developer has very little incentive to do it. I am
looking for something clean & simple, essentially, a clone of your
"gx" / "sf" service. Google has the skills to do it without excessive
overhead & superfluous features. Would it be a waste of time to file
a feature request in the issue tracker for legal access to your "gx" /
"sf" service ? Is it illegal to directly use your "gx" / "sf"
service ?

[Ben Appleton]

I am not a lawyer.  I do not know of any legal restrictions to using /gx or /sf - they merely translate publicly available documents to a custom format.  However sf and gx are private interfaces and subject to change or removal without notice.

[bratliff]

On Jul 16, 9:51 pm, Ben Appleton <apple...@google.com> wrote:
> I am not a lawyer. I do not know of any legal restrictions to using /gx or
> /sf - they merely translate publicly available documents to a custom
> format. However sf and gx are private interfaces and subject to change or
> removal without notice.

Cool. V2 is depreciated. I am guessing the chance of an incompatable
change is almost zero. V3 uses a different interface.