Question

Coordinate System lost after using GeometryReplacer (GeoJSON)

  • 15 February 2021
  • 4 replies
  • 9 views
dbaldacchino1
Rank
Badge +3

So I am noticing that after using a GeometryReplacer, the coordinate system property is lost and gets set to "Unknown" if I first extract with GeoJSON encoding and replace with it later. Is this to be expected?

 

For context, I have a feature with Coordinate System LL84. I used a GeometryExtractor first (GeoJSON encoding), then replaced the geometry with a BoundingBoxReplacer (coordinate system is retained), then replaced the geometry and that's where I noticed the coordinate system being lost. If I use FME Binary encoding when extracting, the coordinate system is retained after replacing geometry. I don't know enough about coordinate systems but thought that the coordinate system should be preserved without having to re-set again, regardless of the encoding used. Thanks.

4 replies

nielsgerrits
Rank
Userlevel 6
Badge +33

I suspect the coordinate system is written in the binary data. This is the case with esrijson:

{"x":0,"y":0,"spatialReference":{"wkid":28992}}

but not with geojson:

{"type":"Point","coordinates":[0,0]}

I think this is expected behaviour.

dbaldacchino1
Rank
Badge +3

Thanks @nielsgerrits​ . This still looks a bit peculiar to me though since it's supposed to just replace the geometry and not touch the coordinate system. For example if I extract with Esri JSON encoding and then replace the geometry once again, the original coordinate system LL84 changes to EPSG:4326. Granted that is technically the same (I suppose), but why change it then?

nielsgerrits
Rank
Userlevel 6
Badge +33

Thanks @nielsgerrits​ . This still looks a bit peculiar to me though since it's supposed to just replace the geometry and not touch the coordinate system. For example if I extract with Esri JSON encoding and then replace the geometry once again, the original coordinate system LL84 changes to EPSG:4326. Granted that is technically the same (I suppose), but why change it then?

No coordinate system specialist either but I believe LL84 and 4326 are the same coordinate systems. If you search for 4326 in the Coordinate System Gallery you will get 3 results, which have different names and descriptions but are the same system.

2021-02-17_08h41_08The EPSG codes are here to help GIS software to function, where a code is less interpretable than a name / description. When checking the Esri-JSON

documentation:

The value of the spatialReference key is a JSON object containing coordinate system data for the features in the data set. In ESRIJSON, coordinate systems are represented by their well known ID, typically an EPSG number. The spatialReference key and value are duplicated in the geometry object of each feature in the dataset. A spatial reference object representing the EPSG:4326 coordinate system is shown below.

{ “wkid“ : 4326 }

The value of the features key is an array of JSON objects, representing the individual features in the data set. Each feature object has two keys, geometry and attributes. The value of the attributes key is a JSON object whose keys and values represent feature attribute names and values. The value of the geometry key is an Esri-JSON geometry object. The various types of geometry objects are listed below.

 

So when FME reads LL84, it writes 4326. I think this is a technical design choice.

 

I can also imagine situations where you want to have multiple geometry columns per feature, having different coordinate systems. So I would prefer extracting and replacing the coordinate system when using the GeometryExtracter / GeometryReplacer.

dbaldacchino1
Rank
Badge +3

No coordinate system specialist either but I believe LL84 and 4326 are the same coordinate systems. If you search for 4326 in the Coordinate System Gallery you will get 3 results, which have different names and descriptions but are the same system.

2021-02-17_08h41_08The EPSG codes are here to help GIS software to function, where a code is less interpretable than a name / description. When checking the Esri-JSON

documentation:

The value of the spatialReference key is a JSON object containing coordinate system data for the features in the data set. In ESRIJSON, coordinate systems are represented by their well known ID, typically an EPSG number. The spatialReference key and value are duplicated in the geometry object of each feature in the dataset. A spatial reference object representing the EPSG:4326 coordinate system is shown below.

{ “wkid“ : 4326 }

The value of the features key is an array of JSON objects, representing the individual features in the data set. Each feature object has two keys, geometry and attributes. The value of the attributes key is a JSON object whose keys and values represent feature attribute names and values. The value of the geometry key is an Esri-JSON geometry object. The various types of geometry objects are listed below.

 

So when FME reads LL84, it writes 4326. I think this is a technical design choice.

 

I can also imagine situations where you want to have multiple geometry columns per feature, having different coordinate systems. So I would prefer extracting and replacing the coordinate system when using the GeometryExtracter / GeometryReplacer.

Thanks again, that makes sense and yeah I noticed that barring the name, those 3 coordinate systems are essentially the same. I just wish it was more clear what is happening and if there are differences in behavior based on the encoding used (such as GeoJSON not storing the coordinate system and thus losing that data once geometry is replaced), that such differences would be made clear to the end user.

Reply


Community Stats

28,723
Posts
109,511
Replies
36,559
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.