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 <knu...@gmail.com> wrote: > On Mon, Jul 26, 2010 at 9:38 AM, Bob Jolliffe <bobjolli...@gmail.com> wrote: >> Hi Jason >> >> On 26 July 2010 04:49, Jason Pickering <jason.p.picker...@gmail.com> 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.picker...@gmail.com >>> tel:+17069260025 >>> >> > > > > -- > 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
