dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

Hi Knut

Spotted this:
http://trac.osgeo.org/gdal/browser/trunk/autotest/ogr/ogr_gml_geom.py?rev=20065

gml_out_precision is failing on win32.

See line 517 [def gml_out_precision(): ]

Can you repeat on something other than windoze and confirm the same
problem exists.

Cheers
Bob

On 26 July 2010 09:17, Knut Staring <knutst@xxxxxxxxx> wrote:
> 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
>