Comments (7)
The plugin uses QGIS's inbuild asWkt() functionality to retrieve WKT representations of geometries.
there should be a space between "polygon" and "z".
Hmm, yes and no. This is where we could get into an argument of who's standard is better
QGIS exports the WKT as polygonz in line with a number of standards. The standard in use probably dates back to the program's roots in PostGIS compatibility which uses one of the standards defining no space.
ISO 13249-3, Information technology - Database languages - SQL Multimedia and Application Packages - Part 3: Spatial
Simple feature access - Part 2: SQL option
But you are right, other standards exist that define the space and if its a problem its a problem.
There is an additional issue: the plugin also returns too many decimals, these are not specified in the GML. But that may be a QGIS issue?"""
You are correct, the extra decimals derive from how QGIS stores coordinates internally. Every coordinate system has different expectations for the number of decimal places in a coordinate (think Lat Long vs UTM). I believe QGIS uses Double type with a set precision regardless, as it probably doesn't want to take a guess and risk losing data. I don't know well enough to explain why the coordinates change very slightly, and its an absolute pain that I have banged my head against a wall about for years.
The Vertex Editor in QGIS seems to default to 4 decimal places for all coordinate systems. This is good for the UTMs, providing micrometre accuracy but terrible for LatLong up to 11 meters.
So what can I do?
I'd be happy to add in the option to configure the number of decimal places exported and specify the format for WKT type specifiers. It probably would not be the default, but could be put in a settings menu.
We could advance that and put some checks on the output coordinate system to determine what 'should' be the precision. Projected Coordinate Systems could be, for example, 4 for meters and 3 for feet (0.1-0.3 millimetre accuracy), Geographic Systems could be raw. The output decimal precision could be set in settings as auto, custom or raw.
I've stayed away from adding a settings menu to try to keep things simple, but if it's causing grief I'll be happy to get to work on it. Let me know what you think.
from qgis3-getwkt.
Interestingly, PostGIS via OGR doesn't even specify its a 2.5 or 3D geometry in its type. Its got the data in the string, but doesn't explicitly specify z. How does you DB systems handle this?
ogr2ogr -f PGDump dump.sql export.gml -lco WRITE_EWKT_GEOM=ON
POLYGON ((722178.52 6178866.39 24.61,722184.83 6178880.97 24.61,722137.52 6178901.05 24.7,722135.5 6178901.91 25.01,722126.66 6178905.66 24.61,722120.48 6178891.19 24.61,722126.3 6178888.7 24.28,722178.52 6178866.39 24.61))
Could we just have an option to remove the z?
Interestingly in PostGIS all of the following return POINT Z (722178.52 6178866.39 24.61)
select st_astext(st_geomfromtext('POINTZ (722178.52 6178866.39 24.61)')); select st_astext(st_geomfromtext('POINT Z (722178.52 6178866.39 24.61)')); select st_astext(st_geomfromtext('POINT (722178.52 6178866.39 24.61)'));
from qgis3-getwkt.
QGIS exports the WKT as polygonz in line with a number of standards. The standard in use probably dates back to the program's roots in PostGIS compatibility which uses one of the standards defining no space.
ISO 13249-3, Information technology - Database languages - SQL Multimedia and Application Packages - Part 3: Spatial
Simple feature access - Part 2: SQL optionBut you are right, other standards exist that define the space and if its a problem its a problem.
The standard I referred to is the OpenGIS Implementation Standard for Geographic Information Simple feature access - Part 1: Common architecture , version 1.2.1, so we are both referring to the same standards (SQL/MM is based on the Simple feature access, and WKT is actually defined in Simple feature access part 1, not part 2).
From Simple feature access part 1:
From the SQL/MM document you referred to above:
I don't yet have access to the latest version of ISO 13249-3, but I would be surprised if the spaces have been removed in there.
Interestingly, PostGIS via OGR doesn't even specify its a 2.5 or 3D geometry in its type. Its got the data in the string, but doesn't explicitly specify z. How does you DB systems handle this?
ogr2ogr -f PGDump dump.sql export.gml -lco WRITE_EWKT_GEOM=ON
POLYGON ((722178.52 6178866.39 24.61,722184.83 6178880.97 24.61,722137.52 6178901.05 24.7,722135.5 6178901.91 25.01,722126.66 6178905.66 24.61,722120.48 6178891.19 24.61,722126.3 6178888.7 24.28,722178.52 6178866.39 24.61))
But that is EWKT (PostGIS specific format, see https://postgis.net/docs/ST_GeomFromEWKT.html, not WKT (OGC standard).
Could we just have an option to remove the z?
That would be against the standard, which seems to be supported, also for 3D, in quite some database systems). I guess the reason it must be there, is that else, it is not possible to differentiate between e.g. Polygon Z
and Polygon M
.
Interestingly in PostGIS all of the following return POINT Z (722178.52 6178866.39 24.61)
select st_astext(st_geomfromtext('POINTZ (722178.52 6178866.39 24.61)')); select st_astext(st_geomfromtext('POINT Z (722178.52 6178866.39 24.61)')); select st_astext(st_geomfromtext('POINT (722178.52 6178866.39 24.61)'));
I guess PostGIS applies the Robustness principle : "Be conservative in what you send, be liberal in what you accept".
I tried now with a Spatialite database in QGIS:
Some additional testing with Spatialite from within QGIS:
SELECT ST_AsText(ST_GeomFromText("POLYGON Z ((722178.52 6178866.39 24.61,722184.83 6178880.97 24.61,722137.52 6178901.05 24.7,722135.5 6178901.91 25.01,722126.66 6178905.66 24.61,722120.48 6178891.19 24.61,722126.3 6178888.7 24.28,722178.52 6178866.39 24.61))")) as wkt FROM "test"
and
SELECT ST_AsText(ST_GeomFromText("POLYGONZ ((722178.52 6178866.39 24.61,722184.83 6178880.97 24.61,722137.52 6178901.05 24.7,722135.5 6178901.91 25.01,722126.66 6178905.66 24.61,722120.48 6178891.19 24.61,722126.3 6178888.7 24.28,722178.52 6178866.39 24.61))")) as wkt FROM "test"
give
POLYGON Z((722178.52 6178866.39 24.61, 722184.83 6178880.97 24.61, 722137.52 6178901.05 24.7, 722135.5 6178901.91 25.01, 722126.66 6178905.66 24.61, 722120.48 6178891.19 24.61, 722126.3 6178888.7 24.28, 722178.52 6178866.39 24.61))
whereas
SELECT ST_AsText(ST_GeomFromText("POLYGON ((722178.52 6178866.39 24.61,722184.83 6178880.97 24.61,722137.52 6178901.05 24.7,722135.5 6178901.91 25.01,722126.66 6178905.66 24.61,722120.48 6178891.19 24.61,722126.3 6178888.7 24.28,722178.52 6178866.39 24.61))")) as wkt FROM "test"
gives
NULL
So the robustness principle seems to apply there as well, POLYGONZ
and POLYGON Z
are accepted as input, and the output is always POLYGON Z
.
So what can I do?
I'd be happy to add in the option to configure the number of decimal places exported and specify the format for WKT type specifiers. It probably would not be the default, but could be put in a settings menu.
We could advance that and put some checks on the output coordinate system to determine what 'should' be the precision. Projected Coordinate Systems could be, for example, 4 for meters and 3 for feet (0.1-0.3 millimetre accuracy), Geographic Systems could be raw. The output decimal precision could be set in settings as auto, custom or raw.
I've stayed away from adding a settings menu to try to keep things simple, but if it's causing grief I'll be happy to get to work on it. Let me know what you think.
As for the format for the WKT, I would definitely suggest to stick to the standard (which, ideally, the QGIS source code should do).
As for the number of decimal places exported, the solution you propose sounds fine to me.
from qgis3-getwkt.
Oops, there is the other problem with standards, me misunderstanding them 🙁.
I'll put in a modifier to change polygonz to polygon z, as well as the same for zm and m values. I agree a fix to qgis core would be better but I should be able to implement this alot quicker. Have you/did you want to raise this at qgis core as an issue? I'm happy to if you would like.
I will tackle the decimal places as well.
That's for your feedback and the time taken to explain the issues. Really appreciated.
from qgis3-getwkt.
Have you/did you want to raise this at qgis core as an issue? I'm happy to if you would like.
I haven't raised this at QGIS core. If you could do that, that would be much appreciated, thanks!
from qgis3-getwkt.
Added code changes to the repo, will do some more tests over the next couple of days. Will release over at qgis when tests are complete.
from qgis3-getwkt.
Closed with submittion to repo on March 26, 2020
from qgis3-getwkt.
Related Issues (9)
- Please explain plugin usefulness HOT 3
- Resizeable text area HOT 1
- Bug with QGIS 3.8 HOT 3
- WKT creates more than just the WKT HOT 3
- Python Error Running Get WKT HOT 3
- Bring Pop Window To Front on Each Click
- Feature Request: Keep Only One Button to Front. Move Rest to Dropdown. HOT 2
- TypeError: 'QVariant' object is not subscriptable HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from qgis3-getwkt.