[gdal-dev] Bogus GeoJSON file or am I doing something wrong? (re-post)

Even Rouault even.rouault at spatialys.com
Tue Sep 24 12:22:30 PDT 2019


On mardi 24 septembre 2019 11:52:22 CEST Simon Eves wrote:
> (re-posting as the first one ~2 weeks ago went into moderation quarantine
> due to attachment size and I don't know if it ever came out again, but
> certainly had no responses)
> 
> When our system imports (using GDAL) the attached GeoJSON file (of unknown
> provenance, via our QA team) the geo (California counties) ends up
> somewhere out in the Pacific and really small and slightly rotated.
> 
> I get the same results whether I import the file directly, or do a
> Shapefile or WKT CSV conversion with ogr2ogr first (forcing to EPSG:4326).
> 
> Is the file bogus, or is GDAL not interpreting the original coordinate
> system correctly?

Its CRS and coordinate encoding is highly unstandard

"crs":{"type":"name","properties":{"name":"urn:ogc:def:crs:EPSG:102243"}},"hc-
transform":{"default":{"crs":"+proj=lcc +lat_1=37.06666666666667 
+lat_2=38.43333333333333 +lat_0=36.5 +lon
_0=-120.5 +x_0=2000000 +y_0=500000 +ellps=GRS80 +units=m +no_defs","scale":
0.000665455608285,"jsonres":15.5,"jsonmarginX":-999,"jsonmarginY":
9851.0,"xoffset":1668099.76286,"yoffset":1116967.85109}}

EPSG:102243 doesn't exist. It is actually ESRI:102243 (the proj string above 
is consistant with that)

But the main issue is the "transform" object that seems to describe a offset & 
scaling strategy to encode coordinates as integer values. You'll have to 
manually apply those corrections

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com


More information about the gdal-dev mailing list