dhis2-users team mailing list archive

[Knut Staring <knutst@xxxxxxxxx>]

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 <knutst@xxxxxxxxx> 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 <bobjolliffe@xxxxxxxxx> wrote:
>> 2010/7/23 Knut Staring <knutst@xxxxxxxxx>:
>>> 2010/7/14 Lars Helge Øverland <larshelge@xxxxxxxxx>:
>>>>
>>>> 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@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~dhis2-devs
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>
>
>
> --
> Cheers,
> Knut Staring
>
>



-- 
Cheers,
Knut Staring