dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

Hi Jason

On 26 July 2010 04:49, Jason Pickering <jason.p.pickering@xxxxxxxxx> wrote:
> Hi Knut,
>
>> It may be that we want to use DHIS as both a repository with full
>> precision (though not ridiculously artifical ones like 15 decimal
>> lat/lon) and have a faster way of renderin. But for a repo, I think
>> something like PostGIS is in order. Or we could just store things as
>> GML...
>
> Well, this is really the issue. If DHIS is going to be a repository,
> any self-respecting GIS geek would not use it if the application
> clipped precision. Although a few meters is not significant in terms
> of rendering a map, it may cause havoc on certain datasets,
> particularly if there are topological relationships between different
> layers. If a facility is related topologically to a road network, and
> the point is shifted a few meters, this may result in disturbance of
> the topology between these layers, rendering DHIS useless as a
> repository. ogr2ogr is perfectly OK as long as we are not dealing with
> these types of layers, but as soon as we start to think about
> relationships to other layers, we need to be very careful about how
> the data is preprocessed.

Would you suggest then that the best place to clip precision would be
when the data is retrieved from the database for the specific view/map
rendering, rather than prior to it being stored?

This would render the current convenience of storing as a geojson
string redundant as we would need to process the string on checkout
anyway.

Can anyone say what the precision is on the shapefiles prior to
ogr2ogr conversion  ie. are we introducing a new level of precision
here or is that 15 digit precision the precision of the source
shapefiles?

Bob

>
>
>> We should be very conscient of not pushing the new, very simple
>> solution too far, for more complex functionality we should rather
>> employ Geoserver and PostGIS - and I still think this is the best
>> solution for a national repository. Our new way of storing orgunit
>> boundaries is a very small subset of such a full blown GIS solution,
>> but has the advantage of being simple, lightweight and portable.
>
> Agreed on both points, namely that the solution is lightweight and
> aimed at thematic mapping but other solutions would be more
> appropriate for use as a repository of GIS data.
>
> Regards,
> Jason
>
>
>
> --
> Jason P. Pickering
> email: jason.p.pickering@xxxxxxxxx
> tel:+17069260025
>