[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