Skip to main content
Question

SQL Azure DB has different vertices placement than same features


Forum|alt.badge.img

Hello,

I am trying to use the change detection transformer to detect any changes that may have occurred from a previous iteration. The original source is being pulled from a SQL spatial DB, and the revised is a GDB file that I converted to geojson files. I've noticed the vertices are slightly different. I have NOT touched the files, I've just imported the geojson files to the SQL DB and then took the same geojson files and tested it against those coming from the SQL DB. Any suggestions?

 

5 replies

redgeographics
Celebrity
Forum|alt.badge.img+49

It looks like it might be a rounding/accuracy issue.

What has happened to the data between the SQL Spatial DB and the GDB? Which coordinates do you see if you inspect the GDB?


Forum|alt.badge.img
redgeographics wrote:

It looks like it might be a rounding/accuracy issue.

What has happened to the data between the SQL Spatial DB and the GDB? Which coordinates do you see if you inspect the GDB?

Hi @redgeographics,

 

I imported the data directly from the GDB to the SQL DB. In order to get the geometry into the DB, I did reproject to LL84. I took the reprojected data and also converted geojson features. Would it be wise to use the coordinate rounder before reprojecting to LL84?


redgeographics
Celebrity
Forum|alt.badge.img+49
david_prosack88 wrote:
Hi @redgeographics,

 

I imported the data directly from the GDB to the SQL DB. In order to get the geometry into the DB, I did reproject to LL84. I took the reprojected data and also converted geojson features. Would it be wise to use the coordinate rounder before reprojecting to LL84?

It's still not exactly clear what's happening. You reprojected to LL84 when loading it into the SQL database, but the coordinates shown in your screenshot are obviously not in LL84. At what point did you reproject them back (and to what coordinate system) to do the comparison?


Forum|alt.badge.img
redgeographics wrote:

It's still not exactly clear what's happening. You reprojected to LL84 when loading it into the SQL database, but the coordinates shown in your screenshot are obviously not in LL84. At what point did you reproject them back (and to what coordinate system) to do the comparison?

When calling the features from the SQL DB, I then reprojected them to EPSG:4087, which is in meters. I was hoping by doing converting them to EPSG:4087 it would be able to get a better match. So before entering the Change Detector transformer both incoming datasets (Original, Revised) are reprojected EPSG:4087.


redgeographics
Celebrity
Forum|alt.badge.img+49
david_prosack88 wrote:

When calling the features from the SQL DB, I then reprojected them to EPSG:4087, which is in meters. I was hoping by doing converting them to EPSG:4087 it would be able to get a better match. So before entering the Change Detector transformer both incoming datasets (Original, Revised) are reprojected EPSG:4087.

Yeah, I'm pretty sure there's a rounding being introduced with all that reprojection. Check the LL84 coordinates and see how many decimals there are. Your errors appear to be in the centimeter range max, 0.0001 degree is about 11 meters so 0.0000001 degree is around a centimeter, if your database stores less digits you can't expect the result after reprojecting to be the same to 3 decimals in meters.


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings