It obviously also depends a bit on the scale - if we are talking about world maps and just national borders, in my experience 2 decimals is more than enough. But for a subdistrict map I think you would at least want 3.
k On Fri, Jul 23, 2010 at 10:11 PM, Knut Staring <knu...@gmail.com> wrote: > There is probably some difference between polygons and points. For the > location of health facilities (points), I think it makes sense to retain 4-5 > decimals. Polygons (which obviously have a lot more coordinates) can probably > do fine with 3-4. Let us settle for 4 overall for now, and then ppl like Jan > and I should do some testing. > > k > > On Fri, Jul 23, 2010 at 9:54 PM, Bob Jolliffe <bobjolli...@gmail.com> wrote: >> 2010/7/23 Knut Staring <knu...@gmail.com>: >>> 2010/7/14 Lars Helge Øverland <larshe...@gmail.com>: >>>> >>>> We are in the process of changing the GIS module in terms of how the >>>> geographical information is persisted and presented. >>>> In the snapshot version we now store the coordinates in JSON format >>>> directly >>>> in the database on the OrganisationUnit.coordinates property. This gives us >>>> a lot more flexibility in the way maps are presented. >>>> Previously maps had to be registered explicitly either in the form of >>>> GeoJson files or Shapefiles. Then the user had to select a map together >>>> with >>>> indicator and period. Now the user can select an orgunit from a tree and >>>> the >>>> children of that orgunit at the level below will be displayed in the map. >>>> In large countries in India it is impossible to display a single map at the >>>> lower levels (eg. for thousands of districts) as the map will be too heavy >>>> and slow to load. Registering and managing maps for every e.g. provinces >>>> will also be too cumbersome. With the current solution there is no more >>>> work >>>> of registering and selecting maps - only the one time job of importing >>>> geographical data/coordinates into the database. >>>> Importing is a 4 step process: >>>> >>>> 1. Convert your shapefiles (or whatever format you have) into GML. >>>> The recommended tool is FWTools, http://fwtools.maptools.org/ . The command >>>> for converting shapefiles into GML is >>>> ogr2ogr -F GML output.gml input.shp >>> >>> One problem is that the conversion to GML seems to generate very large >>> representations, because the GML coordinates are output with 15 >>> decimals, whereas you would normally be happy with 5-6. Here is a >>> comparison of what I get in GeoJSON vs GML (converting from the same >>> shapefile): >>> GeoJSON: 38.415412, 1.750212 >>> GML: 38.415411724082148,1.750212388592194 >> >> I think this is just a question of understanding how many decimal >> points are required/optimal/acceptable or what have you. If you think >> 4 or 5 or 6 is enough then I guess this can be reduced in the xslt >> transform. >> >> Just saw Jan's mail. 3 is fine as well. It could be done at gml2dxf >> stage or at db insertion. Swings 'n roundabouts. The earlier in the >> process the better from an efficiency perspective. But java rounding >> is maybe more efficient than xpath function. Perhaps the best of both >> worlds might be a simple java rounder function available to the xslt. >> Ideally would be a parameter to ogr2ogr but we probably don't want our >> own custom binary. >> >> Bob >> >>> >>> It also seems that there the import process puts a bit too many >>> brackets on points: >>> Example point representation (which also has a ridiculous tail of decimals): >>> [[[[37.270000000000003,-0.69]]]] >>> >>> Example full polygon representation (gets very big when adding >>> hundreds of polygons into a layer): >>> [[[[35.241617396557501,-1.042755167363498],[35.082178302163747,-0.910721897610392],[35.016946729972211,-0.895020643910023],[35.011665399182093,-0.885742630359804],[35.024369140812389,-0.87746378749961],[35.019944242042286,-0.853483690939046],[35.045208986632879,-0.856766680349123],[35.060339285653235,-0.839352562608713],[35.077610664723643,-0.860192408429204],[35.085033075563814,-0.846061280098871],[35.139987463515105,-0.881032254249694],[35.136418996765023,-0.843206506698804],[35.168249720175773,-0.842064597338777],[35.172674618945877,-0.792391540177609],[35.202078784966567,-0.793390710867632],[35.231625689657264,-0.819083671468237],[35.262599981047991,-0.804667065797898],[35.297285477858807,-0.830645503738509],[35.334540270729683,-0.814087818018119],[35.343961022949905,-0.790393198797562],[35.27601741602831,-0.724162455916004],[35.242759305917524,-0.747857075136561],[35.241331919217494,-0.694758289895313],[35.262029026367976,-0.680056206884967],[35.291861408398681,-0.655076939634379],[35.387496317300929,-0.65935909973448],[35.397773501541174,-0.647940006134211],[35.420611688741708,-0.729301048036125],[35.481989316843155,-0.77797493450727],[35.539513000854505,-0.798101086977743],[35.434029123722027,-0.895020643910023],[35.408478901791426,-0.957111965361483],[35.360233231330291,-0.98123480059205],[35.346673057679972,-0.973812389751876],[35.241617396557501,-1.042755167363498]]]] >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~dhis2-devs >>> Post to : dhis2-devs@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~dhis2-devs >>> More help : https://help.launchpad.net/ListHelp >>> >> > > > > -- > Cheers, > Knut Staring > > -- Cheers, Knut Staring _______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : dhis2-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
