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 _______________________________________________ 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
