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
On Wed, Jul 14, 2010 at 10:44 AM, William <[email protected]> wrote:
> On Jul 14, 10:13 am, Ben Appleton <[email protected]> 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
>
> --
> 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
> [email protected].
> To unsubscribe from this group, send email to
> [email protected]<google-maps-js-api-v3%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/google-maps-js-api-v3?hl=en.
>
>
--
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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-maps-js-api-v3?hl=en.
