Hi
The problem using planer projection on big areas was that it was causing drifting points. From what I have tested before I did not find any projection that was handling this correctly. If we for instance select https://epsg.io/25832 as the planer projection in the database and work coordinates from north east in Norway, we are to far east for this projection. So we here need to use https://epsg.io/25835 . So the question was how to transform from UTM35 to UTM32 and back with out drifting points ? We start out with the point 1108142.0,7788000.0 and up with POINT(1104127.00421121 7787535.4833056) in the test case below : select ST_AStexT(ST_Transform(ST_Transform(ST_setSrid(ST_MakePoint(1108142.0,7788000.0),25835),25832),25835)); -> POINT(1104127.00421121 7787535.4833056) - We also tested to by going through degrees , but the points was still drifting select ST_AStexT(ST_Transform(ST_Transform(ST_Transform(ST_Transform(ST_setSrid(ST_MakePoint(1108142.0,7788000.0),25835),4258),25832),4258),25835)); -> POINT(1104127.00421121 7787535.4833056) The tests above I did in our prod database postgis_full_version : POSTGIS="2.2.2 r14797" GEOS="3.5.0-CAPI-1.9.0 r4084" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.9.2, released 2012/10/08" LIBXML="2.7.6" LIBJSON="0.11" TOPOLOGY RASTER So to handle the problem in some cases we had some Java code that we used, based on Cobol code we got from norwegian mapping authority but that was not usable in the database. So we ended using degrees. But when I tested this on my local laptop now the behaviour is totally different, so this is actually is fixed and thats great. select ST_AStexT(ST_Transform(ST_Transform(ST_setSrid(ST_MakePoint(1108142.0,7788000.0),25835),25832),25835)); -> POINT(1108142 778800 POSTGIS="2.5.2 r17328" [EXTENSION] PGSQL="110" GEOS="3.7.2-CAPI-1.11.2 b55d2125" SFCGAL="1.3.6" PROJ="Rel. 6.0.0, March 1st, 2019" GDAL="GDAL 2.4.1, released 2019/03/15" LIBXML="2.9.9" LIBJSON="0.13.1" LIBPROTOBUF="1.3.1" TOPOLOGY RASTER So yes, it seems like can switch to a planer projection now as suggest, we just need to upgrade our databases first, By the way I am not an expert in Geodesy, I just try to use tools available Thanks a lot. Lars ________________________________ From: postgis-users <postgis-users-boun...@lists.osgeo.org> on behalf of Paul Ramsey <pram...@cleverelephant.ca> Sent: Friday, June 7, 2019 5:53 PM To: PostGIS Users Discussion Subject: Re: [postgis-users] Tolerance/SnapTo in Postgis Topology for meter and degrees. Surely there is an “all of Norway” planar projection you can use to handle the integrative whole-country work cases? Even if there isn’t, you can always invent one and add it to the spatial_ref_sys table. P On Jun 7, 2019, at 3:02 AM, Lars Aksel Opsahl <lars.ops...@nibio.no<mailto:lars.ops...@nibio.no>> wrote: Hi We have one issue/problem and that is how to handle Tolerance/SnapTo in a good way when working in degrees. We work on maps that covers all of Norway so we use degrees https://epsg.io/4258 . We also use Postgis Topology, which means that we just have add new lines both for surface and line layers and let Postgis Topology take care generating the surfaces so this samples I just focus on lines. A description and some code pieces to illustrate the problem: A: Layers in meter First we show that this works well when working in meter. I create a Postgis Topology layer with layer_precision 10 meter using https://epsg.io/25833. Then we add 4 horizontal lines and 4 vertical lines using a precision with 2 meter. Postgis Topology handles this nicely and we end with total of 4 lines and not 8 lines as we added, because every second line snaps to the line added before because the distance between the lines are less 2 meter which use as precision we used when adding new lines. The sample code :https://github.com/NibioOpenSource/pgtopo_update_sql/blob/develop/src/test/sql/snapto/snapto_code_example_meter.sql A image of the result :https://github.com/NibioOpenSource/pgtopo_update_sql/blob/develop/src/test/sql/snapto/snapto_code_example_meter.png The green lines are the lines we added, the red lines are the lines that are stored in the edge table. Layers in degrees : But when we are using degrees things starts be more difficult. The reason why we are using degrees is to get a accurate transformations to local UTM zones which are different depending on where in Norway you are. So the problem is how to use tolerances so we get a behavior equal to the test using meter. We can we define the layer in Postgis Topology with quite big value because this is just max value as it seems. So we can adjust the tolerance parameter as we add lines but the problem is that we need to adjust this parameter depending on where we are and what orientation the line has. For vertical lines we need a bigger tolerance than for horizontal lines in Norway. This makes it quite complicated to handle adding new lines. The sample code :https://github.com/NibioOpenSource/pgtopo_update_sql/blob/develop/src/test/sql/snapto/snapto_code_example_degrees.sql A image of the result :https://github.com/NibioOpenSource/pgtopo_update_sql/blob/develop/src/test/sql/snapto/snapto_code_example_degrees.png The green lines are the lines we added, the red lines are the lines that are stored in the edge table. It real life it's impossible to do it this because water, farm land are not built up by horizontal and vertical lines only. Since we use Postgis Topology we could split a line in the different line parts and based on the angle select the best tolerance value but that is complicated and means extra computing. Another problem is that edges then will be broken up into unnecessary small pieces. Any ideas on how to handle this in a better way ? Can “PostGIS Geography Type” help us here ? Thanks Lars _______________________________________________ postgis-users mailing list postgis-users@lists.osgeo.org<mailto:postgis-users@lists.osgeo.org> https://lists.osgeo.org/mailman/listinfo/postgis-users
_______________________________________________ postgis-users mailing list postgis-users@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/postgis-users
