Le vendredi 15 janvier 2016 11:55:07, kimaidou a écrit : > Hi all > > I have just tested QGIS master build againt GDAL "trunk" (build via a git > clone from GDAL github repository & following the doc instructions [1] ). > It works like a charm with a small roads dataset. > > Thanks Even (and other involved devs and funders ) for making this happen ! > > I have seen one first caveat : > > * Export a Shapefile to GeoJSON in QGIS via the "Save as" and choose to > keep only 1 number for decimal precision > * Open this GeoJSON file, toggle edition, and add a new feature > * The new feature geometries are written with default decimal precision > (for example : 6790978.453365888446569 ) and not like the other original > features ( for example : 6790978.4 ) > > We should have a way in QGIS to keep the original decimal precision. Any > clue on this ? Should I open a ticket ?
This is not something that could get fixed easily. When you open the geojson file, there's nothing in it explicitly mentionning the decimal precision (and it could be non uniform). There could be some logic to guess it, but that wouldn't be trivial since json-c returns a IEEE-754 double and not the original ASCII representation. A less user friendly but more reliable way would be to have an open option / env. variable to define the wished precision when you're in update mode. > > Regards > Michaël > > [1] https://trac.osgeo.org/gdal/wiki/BuildingOnUnix > > 2016-01-14 20:57 GMT+01:00 Even Rouault <even.roua...@spatialys.com>: > > Le jeudi 14 janvier 2016 20:38:04, Nyall Dawson a écrit : > > > On 15 Jan 2016 2:39 AM, "Even Rouault" <even.roua...@spatialys.com> > > > > wrote: > > > > A more "streaming-like" approach for the driver not proceeding to > > > > full ingestion of features could be desirable to remove that > > > > limitation, but > > > > > > that's > > > > > > > more involved. A possibility could be to have a "at-hand" parser to > > > > > > delimitate > > > > > > > JSon "Feature" objects and use only json-c to parse each feature. But > > > > > > GeoJSON > > > > > > > is certainly not the more appropriate file format to deal with huge > > > > > > datasets... > > > > > > > > > Even, > > > > > > Editable GeoJSON in OGR is great news! > > > > > > I've got a question regarding the geojson driver you may be able to > > > > assist > > > > > with. Is there any method in the OGR libraries which allow direct > > > parsing of a string to a layer? (Ie, without first writing it out to > > > a file). > > > > > > I'd like to add the ability to directly paste geojson text into QGIS > > > and have it inserted as a feature in the current layer (like how you > > > can currently paste WKT text as a feature). I don't want to have to > > > manually parse the json (that would be a nightmare). > > > > Well, the GeoJSON driver support "filenames" which are in fact GeoJSON > > content: > > > > $ ogrinfo > > '{"type":"Feature","properties":{"foo":"bar"},"geometry":{"type":"Point", > > "coordinates":[2,49]}}' -ro -al > > > > Layer name: OGRGeoJSON > > Geometry: Point > > Feature Count: 1 > > Extent: (2.000000, 49.000000) - (2.000000, 49.000000) > > Layer SRS WKT: > > GEOGCS["WGS 84", > > > > DATUM["WGS_1984", > > > > SPHEROID["WGS 84",6378137,298.257223563, > > > > AUTHORITY["EPSG","7030"]], > > > > AUTHORITY["EPSG","6326"]], > > > > PRIMEM["Greenwich",0, > > > > AUTHORITY["EPSG","8901"]], > > > > UNIT["degree",0.0174532925199433, > > > > AUTHORITY["EPSG","9122"]], > > > > AUTHORITY["EPSG","4326"]] > > > > foo: String (0.0) > > OGRFeature(OGRGeoJSON):0 > > > > foo (String) = bar > > POINT (2 49) > > > > Works also with FeatureCollections. > > Alternatively, you could also put the content in a in-memory GDAL file > > (/vsimem/ virtual file system) and open it. > > > > So you could likely instanciate a temporary layer and get a QGIS feature > > from that. > > > > > > If you are just interested in geometries and not attributes, there's also > > the C function : > > > > OGRGeometryH OGR_G_CreateGeometryFromJson (const char *); > > > > > If I could somehow take advantage of OGR's geojson driver to do the > > > heavy lifting then this work would be trivial. > > > > > > Any ideas? > > > > > > Nyall > > > > -- > > Spatialys - Geospatial professional services > > http://www.spatialys.com > > _______________________________________________ > > Qgis-developer mailing list > > Qgis-developer@lists.osgeo.org > > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
