Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error setting value to CRS on featurecollection #98

Open
kennethhaspeel opened this issue Dec 5, 2017 · 4 comments
Open

Error setting value to CRS on featurecollection #98

kennethhaspeel opened this issue Dec 5, 2017 · 4 comments

Comments

@kennethhaspeel
Copy link

Not sure if it's a bug, something not implemented or just me being stupid but i'm getting an error when deserializing a geojson. I've used geojson.net to process about 20 wfs services but this one is a little different.

the url is : CLICK

Only one difference in the 20 other services and this one and that is the CRS part.
Working:
"crs": { "type": "name", "properties": { "name": "urn:ogc:def:crs:EPSG::31370" } }

Not working:
"crs": { "type": "EPSG", "properties": { "code": "31370" } }

When I do a couple of string replacements, it works so i'm assuming it has something to do with geojson.net and not the service.
A couple of string replacements solve the problem but that's not really the way to go, i think 😉

@matt-lethargic
Copy link
Member

Hi

Looking at the old and new GeoJSON specs it would seem that a CRS with type "ESPG" is not valid.

@kennethhaspeel
Copy link
Author

kennethhaspeel commented Dec 5, 2017

I was afraid of that. So it's the service that is still using "old" specs.
I can request the data in WGS84, which is the geojson default.

Is there anyway to tell geojson.net to ignore the CRS and use the default EPSG:4326 instead?
If i'm understanding correctly, the CRS part is optional
At the moment i'm thinking about deserializing to object, replacing the CRS node, serializing and deserializing to featurecollection. But that's probably way overthinking it.

My apologies if my terminology is not up to par

@matt-lethargic
Copy link
Member

The service isn't even using the old spec, what I was saying is that it doesn't even use the old spec.
"type": "EPSG" wasn't valid at any point and it's this that's causing the exception because it is and never was supported.

In the new RFC the line

"However, where all involved parties have a prior arrangement, alternative coordinate reference systems can be used without risk of data being misinterpreted."

seems to me like there is scope to have something in GeoJSON.Net that can handle this situation.

@matt-lethargic
Copy link
Member

I can't make a change right now as I'm busy, but feel free to put a pull request in

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants