Oh, believe me, I was thrilled at the possibility of making my KML in Google Earth and having my Google Map just show it. How much more easy could life get? When I constructed my Rioni map ( http://lovebunnies.luckypro.biz/rioni/ ) I struggled with those damn polygons for days. So the promise of GeoXML and KML seemed like a godsend. Alas, I ran into the GeoXml Garden Shed Distortion Problem.
And I've put so much time into this project, I'd like to at least try to get my polygons exact. At my amateur level of knowledge, I'm hoping using plain vanilla poly-lines and -gons will be less confusing than the certainly more capable KML. Maybe some day I'll be far enough along I could rewrite my map to be nifty. For the moment, I'm going to try to forgo expanded capability and go for obsessive accuracy. It occurs to me that GeoXml might benefit from some kind of defined Accuracy Levels. I understand the current implementation is trading "accuracy at garden shed level" for "quick draw across all levels of detail." Given that I appear to be the first person to complain about inaccuracy at garden shed level, that's obviously been a good tradeoff. But as more people use the API and other map formats, my problem might turn up more. Maybe. So it would be handy to have some way to say, "For these polys, use no simplification." Perhaps by substituting the plain vanilla drawing routine for the GeoXml one? Then it would be up to the map designer to decide when to trade accuracy for speed. Just a thought. On Mar 6, 1:23 am, Lance Dyas <[email protected]> wrote: > BuckyE wrote: > > Yes, I've been doing that. Satellite goes up to 23 or so before the > > resolution gets too bad to be of further use. Your parser is > > definitely way better than the GGeoXml. But the best so far is not > > "parsing" at all. Just reading as polygons from an XML. And, I think I > > can add some arrays or an array for lines and areas using simple code, > > treating the data the same way I treat my existing XML. I should, in > > theory, be able to append new text right in the romanholiday.xml file, > > right? > > Yup, KML pretty useful features > > 1) the primary usefulness of using KML explicitly is to be able to > point multiple clients > as in if you want maps.google.com to work with it and Google Earth to > work with it > and your own api page to work with it and that ESRI gadget to work with it. > > 2). KML stores styles and you can control what your data looks like. > My GeoXml will give random styes if none are present in the data. > > 3) Google Earth is a pretty easy tool for making it. > > The tree based sidebar of GeoXml is handy and a pretty elaborate thing > to construct > rather like encoding of polygons and polylines (when you have large data > or even holes > inside of polygons). > > GeoXml handles a lot of formats and you can mix and match with > them. Recently one GeoXml user made a translator to modify a Yahoo piped > jsonized rss feed so GeoXml would parse it! > > If GeoXml has way more than you need just parsing the XML yourself is > quite viable > not everybody wants to think that much about it. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Maps API" 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-API?hl=en -~----------~----~----~----~------~----~------~--~---
