dhis2-devs team mailing list archive

[Knut Staring <knutst@xxxxxxxxx>]

On Mon, Jul 26, 2010 at 9:38 AM, Bob Jolliffe <bobjolliffe@xxxxxxxxx> wrote:
> 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?

Quoting myself:

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

Both using ogr2ogr. So 6 vs 15 decimals.

Knut

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



-- 
Cheers,
Knut Staring