Giter VIP home page Giter VIP logo

node-srs's Introduction

Node-Srs

Linux: Build Status

Windows: Build status

This module tries to detect projections, also known as "spatial reference systems". It works similiarly to gdalsrsinfo.

node-srs supports parsing a variety of textual representations of projections, like the formats known as OGC WKT, ESRI WKT, OGC CRS URN, or proj4. It supports shapefiles and GeoJSON. Shapefiles optionally come with a separate .prj and inside the .prj the text is usually in the ESRI WKT format. GeoJSON optionally contains a crs property that declares projection as OGC CRS URN.

Detecting projections is important for applications like TileMill, which - through Mapnik - needs the proj4 representation of a projection to create coordinate transformations for re-projecting vector or raster data on the fly.

node-srs includes a variety of hacks to determine if your projection looks like web mercator (epsg:3857) or wgs84 (epsg:4326) and if so returns the canonical representations of these projections (according to @springmeyer). This ensures applications like TileMill can avoid unneeded projection. It is common for data out in the wild in web mercator projection to store slightly different projection strings based on the software that created the files. node-srs ensures a consistent final proj4 representation is returned for all of the variety of representations of web mercator. This is critical because even mercator to mercator transformations are expensive if proj4 is asked to do this for large datasets.

node-srs does not support looking for, or detecting, projection information in formats like GeoTIFF, PostGIS, or SQLite. Rather for those formats you would need to extract the projection information yourself and then pass it to node-srs.

API

srs.parse(string)

Parse a string of projection specification data and return an object describing the detected projection. If the SRS cannot be parsed, throws a TypeError describing the issue.

Example

Detect a proj4 literal string as spherical mercator:

> var srs = require('srs');
> srs.parse('+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext  +no_defs')
{ proj4: '+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0.0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs +over',
  srid: 3857,
  auth: 'EPSG',
  pretty_wkt: 'PROJCS["WGS 84 / Pseudo-Mercator",\n    GEOGCS["WGS 84",\n        DATUM["WGS_1984",\n            SPHEROID["WGS 84",6378137,298.257223563,\n                AUTHORITY["EPSG","7030"]],\n            AUTHORITY["EPSG","6326"]],\n        PRIMEM["Greenwich",0,\n            AUTHORITY["EPSG","8901"]],\n        UNIT["degree",0.0174532925199433,\n            AUTHORITY["EPSG","9122"]],\n        AUTHORITY["EPSG","4326"]],\n    UNIT["metre",1,\n        AUTHORITY["EPSG","9001"]],\n    PROJECTION["Mercator_1SP"],\n    PARAMETER["central_meridian",0],\n    PARAMETER["scale_factor",1],\n    PARAMETER["false_easting",0],\n    PARAMETER["false_northing",0],\n    EXTENSION["PROJ4","+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext  +no_defs"],\n    AUTHORITY["EPSG","3857"],\n    AXIS["X",EAST],\n    AXIS["Y",NORTH]]',
  esri: false,
  name: 'Google Maps Global Mercator',
  valid: true,
  is_geographic: false,
  input: '+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext  +no_defs' }

Detect a WKT string as WGS84:

> srs.parse('GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]]')
{ input: 'GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]]',
  proj4: '+proj=longlat +ellps=WGS84 +no_defs',
  srid: 4326,
  auth: 'EPSG',
  pretty_wkt: 'GEOGCS["GCS_WGS_1984",\n    DATUM["D_WGS_1984",\n        SPHEROID["WGS_1984",6378137,298.257223563]],\n    PRIMEM["Greenwich",0],\n    UNIT["Degree",0.017453292519943295],\n    AUTHORITY["EPSG","4326"]]',
  esri: false,
  name: 'GCS_WGS_1984',
  valid: true,
  is_geographic: true }

Installation

npm install

Test

npm test

License

BSD, see LICENSE.txt

node-srs's People

Contributors

dmitrig01 avatar mapsam avatar tmcw avatar wilhelmberg avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

node-srs's Issues

expresso tests

@dmitrig01 can you create a tests/ directory and add a new test for the geojson handling using expresso?

.prj files: ESRI WKT vs OGC WKT

Noticed this when testing some UK Ordinance Survey shapefiles in TileMill. These files are projected in EPSG:27700

The WKT definition in the .prj file that comes with the shapefile matches the 'ESRI WKT' text from spatialreference.org. But it seems TileMill interprets this as a 'OCG WKT' because the alignment of the render is off. If I replace the .prj file with the OCG WKT then TileMill renders the shapes correctly.

On spatialreference.org the 'PRJ File' download matches the ESRI style WKT - I'm guessing this is the more common (standard?) format for PRJ files. Is there anything we can do to change the way these files are interpreted to match this? From a users point of view, the SRS auto-detection for these files is wrong even though the .PRJ file is correct.

move ESRI:: fallback test into node-srs

For the .prj file of shapefiles currently millstone does an initial parse test and if it fails, then calls the same test again but with a prepended ESRI::. This triggers the underlying c library used (ogr) to try to parse the shapefile .prj wkt as if it were a variant of a known type written by ESRI software that uses a few different terms in the prj text. node-srs should do this double check rather than millstone (https://github.com/mapbox/millstone/blob/master/lib/millstone.js#L381)

mem leak

==21434== 122 bytes in 1 blocks are definitely lost in loss record 583 of 781
==21434==    at 0xB823: malloc (vg_replace_malloc.c:266)
==21434==    by 0x2A13358: strdup (in /usr/lib/system/libsystem_c.dylib)
==21434==    by 0x2F336834: VSIStrdup (in /Users/dane/projects/node-srs/lib/_srs.node)
==21434==    by 0x2F32DBFD: CPLStrdup (in /Users/dane/projects/node-srs/lib/_srs.node)
==21434==    by 0x2F3036C3: OGRSpatialReference::exportToProj4(char**) const (in /Users/dane/projects/node-srs/lib/_srs.node)
==21434==    by 0x2F2F4D71: parse(v8::Arguments const&) (in /Users/dane/projects/node-srs/lib/_srs.node)
==21434==    by 0x100086CED: v8::internal::Builtin_HandleApiCall(v8::internal::(anonymous namespace)::BuiltinArguments<(v8::internal::BuiltinExtraArguments)1>) (in /usr/local/bin/node)
==21434==    by 0x1008E0ECF: ???
==21434==    by 0x1008DEF07: ???
==21434==    by 0x7FFF5FBFF177: ???
==21434==    by 0x7FFF5FBFF1E7: ???
==21434==    by 0x7F0000000000: ???

Compile error when npm installing srs

From dependency of npm install millstone:

CXX(target) Release/obj.target/osr/deps/osr/src/ogr_srs_validate.o
CXX(target) Release/obj.target/osr/deps/osr/src/ogr_srs_xml.o
CXX(target) Release/obj.target/osr/deps/osr/src/ogr_srsnode.o
../deps/osr/src/ogr_srsnode.cpp:159:9: warning: 'this' pointer cannot be null in
well-defined C++ code; comparison may be assumed to always evaluate to
false [-Wtautological-undefined-compare]
if( this == NULL )
^~~~ ~~~~
1 warning generated.
CXX(target) Release/obj.target/osr/deps/osr/src/ogrct.o
../deps/osr/src/ogrct.cpp:772:9: warning: using integer absolute value function
'abs' when argument is of floating point type [-Wabsolute-value]
abs(dfSourceToRadians * dfTargetFromRadians - 1.0) < 1e-10 )
^
../deps/osr/src/ogrct.cpp:772:9: note: use function 'std::abs' instead
abs(dfSourceToRadians * dfTargetFromRadians - 1.0) < 1e-10 )
^~~
std::abs
../deps/osr/src/ogrct.cpp:772:9: note: include the header or explicitly
provide a declaration for 'std::abs'
1 warning generated.
CXX(target) Release/obj.target/osr/deps/osr/src/ogrspatialreference.o
LIBTOOL-STATIC Release/osr.a
CXX(target) Release/obj.target/srs/src/srs.o
In file included from ../src/srs.cc:6:
../node_modules/nan/nan.h:261:25: error: redefinition of '_NanEnsureLocal'
NAN_INLINE v8::Local NanEnsureLocal(v8::Local val) {
^
../node_modules/nan/nan.h:256:25: note: previous definition is here
NAN_INLINE v8::Local NanEnsureLocal(v8::Handle val) {
^
../node_modules/nan/nan.h:661:13: error: no member named 'smalloc' in namespace
'node'
, node::smalloc::FreeCallback callback
~~~~~~^
../node_modules/nan/nan.h:672:12: error: no matching function for call to 'New'
return node::Buffer::New(v8::Isolate::GetCurrent(), data, size);
^~~~~~~~~~~~~~~~~
/var/root/.node-gyp/4.2.6/include/node/node_buffer.h:31:40: note: candidate
function not viable: no known conversion from 'uint32_t'
(aka 'unsigned int') to 'enum encoding' for 3rd argument
NODE_EXTERN v8::MaybeLocalv8::Object New(v8::Isolate* isolate,
^
/var/root/.node-gyp/4.2.6/include/node/node_buffer.h:43:40: note: candidate
function not viable: 2nd argument ('const char ') would lose const
qualifier
NODE_EXTERN v8::MaybeLocalv8::Object New(v8::Isolate
isolate,
^
/var/root/.node-gyp/4.2.6/include/node/node_buffer.h:28:40: note: candidate
function not viable: requires 2 arguments, but 3 were provided
NODE_EXTERN v8::MaybeLocalv8::Object New(v8::Isolate* isolate, size_t length);
^
/var/root/.node-gyp/4.2.6/include/node/node_buffer.h:36:40: note: candidate
function not viable: requires 5 arguments, but 3 were provided
NODE_EXTERN v8::MaybeLocalv8::Object New(v8::Isolate* isolate,
^
In file included from ../src/srs.cc:6:
../node_modules/nan/nan.h:676:12: error: no viable conversion from
'v8::MaybeLocalv8::Object' to 'v8::Localv8::Object'
return node::Buffer::New(v8::Isolate::GetCurrent(), size);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/var/root/.node-gyp/4.2.6/include/node/v8.h:210:7: note: candidate constructor
(the implicit copy constructor) not viable: no known conversion from
'v8::MaybeLocalv8::Object' to 'const v8::Localv8::Object &' for 1st
argument
class Local {
^
/var/root/.node-gyp/4.2.6/include/node/v8.h:210:7: note: candidate constructor
(the implicit move constructor) not viable: no known conversion from
'v8::MaybeLocalv8::Object' to 'v8::Localv8::Object &&' for 1st
argument
class Local {
^
/var/root/.node-gyp/4.2.6/include/node/v8.h:214:13: note: candidate template
ignored: could not match 'Local' against 'MaybeLocal'
V8_INLINE Local(Local that)
^
/var/root/.node-gyp/4.2.6/include/node/v8.h:326:13: note: candidate template
ignored: could not match 'S ' against 'v8::MaybeLocalv8::Object'
V8_INLINE Local(S
that)
^
In file included from ../src/srs.cc:6:
../node_modules/nan/nan.h:683:26: error: no member named 'Use' in namespace
'node::Buffer'
return node::Buffer::Use(v8::Isolate::GetCurrent(), data, size);
~~~~~~~~~~~~~~^
In file included from ../src/srs.cc:2:
/var/root/.node-gyp/4.2.6/include/node/v8.h:221:5: error: assigning to
'v8::Primitive *volatile' from incompatible type 'v8::Value *'
TYPE_CHECK(T, S);
^~~~~~~~~~~~~~~~
/var/root/.node-gyp/4.2.6/include/node/v8.h:180:37: note: expanded from macro
'TYPE_CHECK'
(static_cast<T volatile
>(0)) = static_cast<S
>(0);
^ ~~~~~~~~~~~~~~~~~~
../node_modules/nan/nan.h:414:12: note: in instantiation of function template
specialization 'v8::Localv8::Primitive::Localv8::Value' requested here
return NanEscapeScope(NanNew(v8::Undefined(v8::Isolate::GetCurrent())));
^
../node_modules/nan/nan.h:398:30: note: expanded from macro 'NanEscapeScope'

define NanEscapeScope(val) scope.Escape(_NanEnsureLocal(val))

                         ^

In file included from ../src/srs.cc:2:
/var/root/.node-gyp/4.2.6/include/node/v8.h:221:5: error: assigning to
'v8::Boolean volatile' from incompatible type 'v8::Value *'
TYPE_CHECK(T, S);
^~~~~~~~~~~~~~~~
/var/root/.node-gyp/4.2.6/include/node/v8.h:180:37: note: expanded from macro
'TYPE_CHECK'
*(static_cast<T
volatile_>(0)) = static_cast<S_>(0);
^ ~~~~~~~~~~~~~~~~~~
../node_modules/nan/nan.h:424:12: note: in instantiation of function template
specialization 'v8::Localv8::Boolean::Localv8::Value' requested here
return NanEscapeScope(NanNew(v8::True(v8::Isolate::GetCurrent())));
^
../node_modules/nan/nan.h:398:30: note: expanded from macro 'NanEscapeScope'

define NanEscapeScope(val) scope.Escape(_NanEnsureLocal(val))

                         ^

In file included from ../src/srs.cc:2:
/var/root/.node-gyp/4.2.6/include/node/v8.h:221:5: error: assigning to
'v8::Function volatile' from incompatible type 'v8::Value *'
TYPE_CHECK(T, S);
^~~~~~~~~~~~~~~~
/var/root/.node-gyp/4.2.6/include/node/v8.h:180:37: note: expanded from macro
'TYPE_CHECK'
*(static_cast<T
volatile_>(0)) = static_cast<S_>(0);
^ ~~~~~~~~~~~~~~~~~~
../node_modules/nan/nan.h:1514:12: note: in instantiation of function template
specialization 'v8::Localv8::Function::Localv8::Value' requested here
return NanEscapeScope(NanNew(handle)->Get(kCallbackIndex)
^
../node_modules/nan/nan.h:398:30: note: expanded from macro 'NanEscapeScope'

define NanEscapeScope(val) scope.Escape(_NanEnsureLocal(val))

                         ^

In file included from ../src/srs.cc:2:
/var/root/.node-gyp/4.2.6/include/node/v8.h:221:5: error: assigning to
'v8::Object volatile' from incompatible type 'v8::Value *'
TYPE_CHECK(T, S);
^~~~~~~~~~~~~~~~
/var/root/.node-gyp/4.2.6/include/node/v8.h:180:37: note: expanded from macro
'TYPE_CHECK'
*(static_cast<T
volatile_>(0)) = static_cast<S_>(0);
^ ~~~~~~~~~~~~~~~~~~
../node_modules/nan/nan.h:1632:12: note: in instantiation of function template
specialization 'v8::Localv8::Object::Localv8::Value' requested here
return NanEscapeScope(handle->Get(NanNew(key)).Asv8::Object());
^
../node_modules/nan/nan.h:398:30: note: expanded from macro 'NanEscapeScope'

define NanEscapeScope(val) scope.Escape(_NanEnsureLocal(val))

                         ^

9 errors generated.
make: *** [Release/obj.target/srs/src/srs.o] Error 1
gyp ERR! build error
gyp ERR! stack Error: make failed with exit code: 2
gyp ERR! stack at ChildProcess.onExit (/opt/local/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:276:23)
gyp ERR! stack at emitTwo (events.js:87:13)
gyp ERR! stack at ChildProcess.emit (events.js:172:7)
gyp ERR! stack at Process.ChildProcess._handle.onexit (internal/child_process.js:200:12)
gyp ERR! System Darwin 14.5.0
gyp ERR! command "/opt/local/bin/node" "/opt/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "build" "--fallback-to-build" "--module=/Users/jerome/Documents/MapBox/project/TopoAuvergne/node_modules/millstone/node_modules/srs/lib/binding/node-v46-darwin-x64/srs.node" "--module_name=srs" "--module_path=/Users/jerome/Documents/MapBox/project/TopoAuvergne/node_modules/millstone/node_modules/srs/lib/binding/node-v46-darwin-x64"
gyp ERR! cwd /Users/jerome/Documents/MapBox/project/TopoAuvergne/node_modules/millstone/node_modules/srs
gyp ERR! node -v v4.2.6
gyp ERR! node-gyp -v v3.2.1
gyp ERR! not ok
node-pre-gyp ERR! build error
node-pre-gyp ERR! stack Error: Failed to execute '/opt/local/bin/node /opt/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js build --fallback-to-build --module=/Users/jerome/Documents/MapBox/project/TopoAuvergne/node_modules/millstone/node_modules/srs/lib/binding/node-v46-darwin-x64/srs.node --module_name=srs --module_path=/Users/jerome/Documents/MapBox/project/TopoAuvergne/node_modules/millstone/node_modules/srs/lib/binding/node-v46-darwin-x64' (1)
node-pre-gyp ERR! stack at ChildProcess. (/Users/jerome/Documents/MapBox/project/TopoAuvergne/node_modules/millstone/node_modules/srs/node_modules/node-pre-gyp/lib/util/compile.js:83:29)
node-pre-gyp ERR! stack at emitTwo (events.js:87:13)
node-pre-gyp ERR! stack at ChildProcess.emit (events.js:172:7)
node-pre-gyp ERR! stack at maybeClose (internal/child_process.js:821:16)
node-pre-gyp ERR! stack at Process.ChildProcess._handle.onexit (internal/child_process.js:211:5)
node-pre-gyp ERR! System Darwin 14.5.0
node-pre-gyp ERR! command "/opt/local/bin/node" "/Users/jerome/Documents/MapBox/project/TopoAuvergne/node_modules/millstone/node_modules/srs/node_modules/.bin/node-pre-gyp" "install" "--fallback-to-build"
node-pre-gyp ERR! cwd /Users/jerome/Documents/MapBox/project/TopoAuvergne/node_modules/millstone/node_modules/srs
node-pre-gyp ERR! node -v v4.2.6
node-pre-gyp ERR! node-pre-gyp -v v0.6.9
node-pre-gyp ERR! not ok
Failed to execute '/opt/local/bin/node /opt/local/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js build --fallback-to-build --module=/Users/jerome/Documents/MapBox/project/TopoAuvergne/node_modules/millstone/node_modules/srs/lib/binding/node-v46-darwin-x64/srs.node --module_name=srs --module_path=/Users/jerome/Documents/MapBox/project/TopoAuvergne/node_modules/millstone/node_modules/srs/lib/binding/node-v46-darwin-x64' (1)
npm ERR! Darwin 14.5.0
npm ERR! argv "/opt/local/bin/node" "/opt/local/bin/npm" "install" "millstone"
npm ERR! node v4.2.6
npm ERR! npm v2.14.17
npm ERR! code ELIFECYCLE

npm ERR! [email protected] install: node-pre-gyp install --fallback-to-build
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] install script 'node-pre-gyp install --fallback-to-build'.
npm ERR! This is most likely a problem with the srs package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! node-pre-gyp install --fallback-to-build
npm ERR! You can get information on how to open an issue for this project with:
npm ERR! npm bugs srs
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!
npm ERR! npm owner ls srs
npm ERR! There is likely additional logging output above.

My clang:

clang --version
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin14.5.0
Thread model: posix

Any help would be appreciated :-)

avoid warnings from ogr that report as errors

Node-srs currently tries parsing a .prj and if it fails back to pre-pending ESRI:: and attempting to parse again. The reason for this is that I could not get the MorphFromESRI check working in C++. It also will continue to parse what ever it can even if the proj conversion fails, so that some info can be gleaned from the projection info.

The outcome of this approach is that ogr reports to stdout as if there were fatal errors when in fact they are harmless and the parse succeeds on the second try. Muffling a potential error on the second try seems like a lesser evil than scaring users with lots of "ERROR 6: No translation for Mercator_Auxiliary_Sphere to PROJ.4 format is known." in there terminal when its likely not a problem.

So, the task here is to comment ogr's error output for failed translations.

GDAL data files not being loaded on windows

Because of an oddity of gyp on windows that tries to relativize paths passed for actions and was turning false into ../false and broke the expectation that the boolean would be passed unchanged to gen_settings.py

Avoid full read of geojson

This is bad:

var file_data = fs.readFileSync(arg);
.

Options:

  • partial read with streaming json parser?
  • just read a chunk and try to detect without actually parsing into JSON?
  • just remove this detection code altogether?

Error types for failure states?

I just started to work on an API section for the readme here, and I'm able to reproduce a TypeError when something fails in the ESRI parser, but it looks like there are more ways for node-srs to throw. I'm wondering if all these will be TypeErrors, and what their messages will be: it would be convenient to have pretty simple & understandable failure states that we can differentiate and present to users.

lib/_srs.node: undefined symbol: VSIStatL

Version 0.3.3 broke compatibility with node 0.8.9, raising this error on load:

millstone/node_modules/srs/lib/_srs.node: undefined symbol: VSIStatL
    at Object.Module._extensions..node (module.js:485:11)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.require (module.js:362:17)
    at require (module.js:378:17)
    at Object.<anonymous> (/home/ubuntu/www/node-windshaft/shared/node_modules/windshaft/node_modules/grainstore/node_modules/millstone/node_modules/srs/lib/srs.js:6:11)
    at Module._compile (module.js:449:26)
    at Object.Module._extensions..js (module.js:467:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)

module.js:485
  process.dlopen(filename, module.exports);
          ^

Works fine with node-0.8.18, so could be a node issue, still it's worth noticing (and if simple maybe also fixing?)

lib/_srs.node: undefined symbol: VSIFOpenL with internal libosr at 0.3.4

(First issue report. Apologies if I bungle ...)

Using Ubuntu 12.04 and node 0.10.21, I installed node-srs without linking against external shared gdal:

git clone git://github.com/springmeyer/node-srs.git
cd node-srs
npm install

When running 'npm test', I get:

Error: /home/matt/node-srs/lib/_srs.node: undefined symbol: VSIFOpenL
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)
    at Object.<anonymous> (/home/matt/node-srs/lib/srs.js:6:11)
    ...

If I install against shared gdal, e.g.

npm install --shared_gdal

the tests run fine. (This is affecting the build of Tilemill, which depends on millstone/srs).

Support QGIS .qpj files

Turns out QGIS writes its own projection file - some variant of OGC WKT with extras like EXTENSION["PROJ4_GRIDS". Got a hold of one from a user running QGIS 1.8:

PROJCS["unnamed",GEOGCS["Clarke 1866",DATUM["unknown",SPHEROID["clrk66",6378206.4,294.9786982139006],EXTENSION["PROJ4_GRIDS","@conus,@alaska,@ntv2_0.gsb,@ntv1_can.dat"]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",35.83333333333334],PARAMETER["central_meridian",-90.5],PARAMETER["scale_factor",0.9999333333333333],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["Foot_US",0.3048006096012192]]

how to convince ogr to successfully parse ESRI wkt variants

WKT like the below (from http://dcatlas.dcgis.dc.gov/catalog/) should resolve to EPSG:26985

Sample shapefile is: http://dcatlas.dcgis.dc.gov/download/BicycleLane.zip

PROJCS["NAD_1983_StatePlane_Maryland_FIPS_1900",GEOGCS["GCS_North_American_1983",DATUM["D_North_American_1983",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Lambert_Conformal_Conic"],PARAMETER["False_Easting",400000.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",-77.0],PARAMETER["Standard_Parallel_1",38.3],PARAMETER["Standard_Parallel_2",39.45],PARAMETER["Latitude_Of_Origin",37.66666666666666],UNIT["Meter",1.0]]

OGR is unable to parse it:

ERROR 6: No translation for Lambert_Conformal_Conic to PROJ.4 format is known.
OGR Error type #1 problem occured when converting to proj4 format PROJCS["NAD_1983_StatePlane_Maryland_FIPS_1900",GEOGCS["GCS_North_American_1983",DATUM["D_North_American_1983",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Lambert_Conformal_Conic"],PARAMETER["False_Easting",400000.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",-77.0],PARAMETER["Standard_Parallel_1",38.3],PARAMETER["Standard_Parallel_2",39.45],PARAMETER["Latitude_Of_Origin",37.66666666666666],UNIT["Meter",1.0]].

But ogr can convert from epsg code to:

PROJCS["NAD83 / Maryland",
    GEOGCS["NAD83",
        DATUM["North_American_Datum_1983",
            SPHEROID["GRS 1980",6378137,298.257222101,
                AUTHORITY["EPSG","7019"]],
            TOWGS84[0,0,0,0,0,0,0],
            AUTHORITY["EPSG","6269"]],
        PRIMEM["Greenwich",0,
            AUTHORITY["EPSG","8901"]],
        UNIT["degree",0.01745329251994328,
            AUTHORITY["EPSG","9122"]],
        AUTHORITY["EPSG","4269"]],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    PROJECTION["Lambert_Conformal_Conic_2SP"],
    PARAMETER["standard_parallel_1",39.45],
    PARAMETER["standard_parallel_2",38.3],
    PARAMETER["latitude_of_origin",37.66666666666666],
    PARAMETER["central_meridian",-77],
    PARAMETER["false_easting",400000],
    PARAMETER["false_northing",0],
    AUTHORITY["EPSG","26985"]]

on linux, darwin module is being installed.

On linux, we should be getting node_modules/srs/lib/binding/node-v11-linux-x64/srs.node, but we're instead getting node_modules/srs/lib/binding/node-v14-darwin-x64/srs.node.

Anything we can do to debug this? Why is it installing a mac binary on linux?

Not recognizing projection

The following projection file content returns undefined for the proj4 parameter:

PROJCS["NAD_1983_StatePlane_Maryland_FIPS_1900",GEOGCS["GCS_North_American_1983",DATUM["D_North_American_1983",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Lambert_Conformal_Conic"],PARAMETER["False_Easting",400000.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",-77.0],PARAMETER["Standard_Parallel_1",38.3],PARAMETER["Standard_Parallel_2",39.45],PARAMETER["Latitude_Of_Origin",37.66666666666666],UNIT["Meter",1.0]]

result object after running the projection file data through srs.parse:

{ input: 'PROJCS["NAD_1983_StatePlane_Maryland_FIPS_1900",GEOGCS["GCS_North_American_1983",DATUM["D_North_American_1983",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Lambert_Conformal_Conic"],PARAMETER["False_Easting",400000.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",-77.0],PARAMETER["Standard_Parallel_1",38.3],PARAMETER["Standard_Parallel_2",39.45],PARAMETER["Latitude_Of_Origin",37.66666666666666],UNIT["Meter",1.0]]',
  proj4: undefined,
  srid: undefined,
  auth: undefined,
  pretty_wkt: 'PROJCS["NAD_1983_StatePlane_Maryland_FIPS_1900",\n    GEOGCS["GCS_North_American_1983",\n        DATUM["D_North_American_1983",\n            SPHEROID["GRS_1980",6378137.0,298.257222101]],\n        PRIMEM["Greenwich",0.0],\n        UNIT["Degree",0.0174532925199433],\n        AUTHORITY["EPSG","4269"]],\n    PROJECTION["Lambert_Conformal_Conic"],\n    PARAMETER["False_Easting",400000.0],\n    PARAMETER["False_Northing",0.0],\n    PARAMETER["Central_Meridian",-77.0],\n    PARAMETER["Standard_Parallel_1",38.3],\n    PARAMETER["Standard_Parallel_2",39.45],\n    PARAMETER["Latitude_Of_Origin",37.66666666666666],\n    UNIT["Meter",1.0]]',
  esri: false,
  name: 'NAD_1983_StatePlane_Maryland_FIPS_1900',
  valid: false,
  is_geographic: false }

sha version mismatch on npm

Hey,

It seems the just published 0.4.2 has been uploaded to npm with a wrong sha1, causing it to fail npm install and breaking tests running and deploys everywhere:

➜  vizz  npm install srs
npm http GET https://registry.npmjs.org/srs
npm http 304 https://registry.npmjs.org/srs
npm http GET https://registry.npmjs.org/srs/-/srs-0.4.2.tgz
npm http 200 https://registry.npmjs.org/srs/-/srs-0.4.2.tgz
npm ERR! Error: shasum check failed for /var/folders/tn/t28x6xb571gfgm6yz4dfjqd00000gn/T/npm-17813-HsXs4kp4/1403263846990-0.5543835323769599/tmp.tgz
npm ERR! Expected: 6bc4df3beb3e89d75024a2a9e8930451df67758f
npm ERR! Actual:   5c72ff8172e0b9d4703578bb3b18ecc5f4c49002
npm ERR! From:     https://registry.npmjs.org/srs/-/srs-0.4.2.tgz
npm ERR!     at /usr/local/Cellar/node/0.10.26/lib/node_modules/npm/node_modules/sha/index.js:38:8
npm ERR!     at ReadStream.<anonymous> (/usr/local/Cellar/node/0.10.26/lib/node_modules/npm/node_modules/sha/index.js:85:7)
npm ERR!     at ReadStream.EventEmitter.emit (events.js:117:20)
npm ERR!     at _stream_readable.js:920:16
npm ERR!     at process._tickCallback (node.js:415:13)
npm ERR! If you need help, you may report this *entire* log,
npm ERR! including the npm and node versions, at:
npm ERR!     <http://github.com/npm/npm/issues>

npm ERR! System Darwin 13.1.0
npm ERR! command "/usr/local/Cellar/node/0.10.26/bin/node" "/usr/local/bin/npm" "install" "srs"
npm ERR! cwd /Users/zenitram/code/vizz
npm ERR! node -v v0.10.26
npm ERR! npm -v 1.4.3
npm ERR!
npm ERR! Additional logging details can be found in:
npm ERR!     /Users/zenitram/code/vizz/npm-debug.log
npm ERR! not ok code 0

This could be a bug related with publishing using node 0.11:
https://twitter.com/npm_support/status/467873731931828224

We're going to force 0.4.1 for the time being, although you probably want to fix this

detect this esri mercator variant as true spherical mercator?

PROJCS["Mercator_1SP",GEOGCS["GCS_Geographic Coordinate System",DATUM["D_WGS_1984_MAJOR_AUXILIARY_SPHERE",SPHEROID["Sphere_Radius_6378137_m",6378137,0]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Mercator"],PARAMETER["central_meridian",0],PARAMETER["standard_parallel_1",0],PARAMETER["false_easting",0],PARAMETER["false_northing",0],UNIT["Meter",1]]

downstream issue: http://support.mapbox.com/discussions/tilemill/3292-failed-to-import-zipped-shp-with-index#comment_21991607

more info: http://www.remotesensing.org/geotiff/proj_list/mercator_1sp.html

visual studio 2014 test failures

From https://ci.appveyor.com/project/Mapbox/node-srs/build/1.0.11/job/erhhc66r9j5g5ax4#L710.

It looks like the data files are not being loaded correctly when osr is compiled with visual studio 2014.

 maryland ESRI variant
621    √ detects proj if parsed as ESRI:: 
622 
623  GeoJSON
624ERROR 4: Unable to open EPSG support file gcs.csv.
625Try setting the GDAL_DATA environment variable to point to the
626directory containing EPSG csv files.
627ERROR 4: Unable to open EPSG support file gcs.csv.
628Try setting the GDAL_DATA environment variable to point to the
629directory containing EPSG csv files.
630    1) should detect mercator
631
    √ should detect wgs84 
632    √ should detect wgs84 2 
633    √ should detect with no ext 
634 
635  throws on invalid input
636    √ detects proj if parsed as ESRI:: 
637    √ init=epsg:3857 
638    √ +init=epsg 
639ERROR 4: Unable to open EPSG support file gcs.csv.
640Try setting the GDAL_DATA environment variable to point to the
641directory containing EPSG csv files.
642ERROR 4: Unable to open EPSG support file gcs.csv.
643Try setting the GDAL_DATA environment variable to point to the
644directory containing EPSG csv files.
645    √ +init=epsg:500 
646 
647  qgis qpj format
648    √ detects custom grids inside qgis transverse mercator projection 
649 
650  OSGB 1936
651    √ should report that it was parsed as esri if ESRI:: was manually prepended 
652    √ should detect OGC format for OSGB 1936 / British National Grid 
653    √ should detect correct proj4 for ESRI format for OSGB 1936 / British National Grid 
654    √ should detect correct srid for ESRI format for OSGB 1936 / British National Grid 
655 
656  Mercator
657    √ should detect non-spherical mercator 
658    √ should detect qgis/ogr wkt 
659    √ should detect qgis/ogr wkt 
660    √ should detect sr-org produced by older ogr version 
661    √ should detect sr-ogr6 
662    √ should detect http://prj2epsg.org/epsg/3857 
663    √ should detect +over stripped 
664    √ should detect proj 3857 
665    √ should detect 900913 
666    √ should detect esri 900913 
667    √ should detect esri 900913 hint 
668    √ should detect esri webmerc 
669    √ should detect esri webmerc hint 
670    √ should detect esri webmerc aux 
671    √ should detect webmerc aux hint 
672    √ should detect esri webmerc aux2 
673    √ should detect esri webmerc aux2 hint 
674    √ should detect osm_landusages 
675    √ should detect bogus proj 1 
676    √ should detect bogus proj 2 
677    √ should detect sr.org mercator1sp 
678    √ should detect sr.org messed up mercator2sp 
679    √ should detect openstreetmapdata.com as 3857 
680    √ should detect +init=epsg:3857 as 3857 
681    √ should detect +init=esri:102100 as 3857 
682    √ should detect +init=esri:102113 as 3857 
683    √ should detect +init=epsg:3785 as 3857 
684    √ should detect +init=osgeo:41001 as 3857 
685 
686  WGS84
687    √ should detect wgs84 proj4 init detection 
688    √ should detect wgs84 proj4 literal from gdal trunk detection 
689    √ should detect wgs84 proj4 literal +datum will trigger addition to towgs detection 
690    √ should detect wgs84 wkt detection 
691ERROR 4: Unable to open EPSG support file gcs.csv.
692Try setting the GDAL_DATA environment variable to point to the
693directory containing EPSG csv files.
694ERROR 4: Unable to open EPSG support file gcs.csv.
695Try setting the GDAL_DATA environment variable to point to the
696directory containing EPSG csv files.
697    2) should detect wgs84 epsg detection
698    √ should detect wgs84 common name detection 
699    √ should detect wgs84 proj4 literal no datum detection 
700    √ should detect wgs84 wkt from prj file 
701    √ should detect wgs84 wkt from another prj file 
702 
703  #split_proj
704    √ splits on spaces 
705 
706  Version check
707    √ test version updated for release 
708 
709 
710�[92m  51 passing (140ms)
711  2 failing
712 
713  1) GeoJSON should detect mercator:
714     Error: OGR Error type #1 problem occured importing from srs wkt: epsg:900913.
715
716      at Error (native)
717      at Object.parse (C:\projects\node-srs\lib\srs.js:83:22)
718      at Context.<anonymous> (C:\projects\node-srs\test\geojson.test.js:8:24)
719      at callFn (C:\projects\node-srs\node_modules\mocha\lib\runnable.js:250:21)
720      at Test.Runnable.run (C:\projects\node-srs\node_modules\mocha\lib\runnable.js:243:7)
721      at Runner.runTest (C:\projects\node-srs\node_modules\mocha\lib\runner.js:373:10)
722      at C:\projects\node-srs\node_modules\mocha\lib\runner.js:451:12
723      at next (C:\projects\node-srs\node_modules\mocha\lib\runner.js:298:14)
724      at C:\projects\node-srs\node_modules\mocha\lib\runner.js:308:7
725      at next (C:\projects\node-srs\node_modules\mocha\lib\runner.js:246:23)
726      at Immediate._onImmediate (C:\projects\node-srs\node_modules\mocha\lib\runner.js:275:5)
727      at processImmediate [as _immediateCallback] (timers.js:374:17)
728
729  2) WGS84 should detect wgs84 epsg detection:
730     Error: OGR Error type #1 problem occured importing from srs wkt: EPSG:4326.
731
732      at Error (native)
733      at Object.parse (C:\projects\node-srs\lib\srs.js:83:22)
734      at Context.<anonymous> (C:\projects\node-srs\test\shapefile.4326.test.js:33:26)
735      at callFn (C:\projects\node-srs\node_modules\mocha\lib\runnable.js:250:21)
736      at Test.Runnable.run (C:\projects\node-srs\node_modules\mocha\lib\runnable.js:243:7)
737      at Runner.runTest (C:\projects\node-srs\node_modules\mocha\lib\runner.js:373:10)
738      at C:\projects\node-srs\node_modules\mocha\lib\runner.js:451:12
739      at next (C:\projects\node-srs\node_modules\mocha\lib\runner.js:298:14)
740      at C:\projects\node-srs\node_modules\mocha\lib\runner.js:308:7
741      at next (C:\projects\node-srs\node_modules\mocha\lib\runner.js:246:23)
742      at Immediate._onImmediate (C:\projects\node-srs\node_modules\mocha\lib\runner.js:275:5)
743      at processImmediate [as _immediateCallback] (timers.js:374:17)
744
745 

Failed 900913 detection

The .prj from this shapefile should be detected as 900913, but is not. I don't remember what tool or parameters I used to reproject it (from Maryland State Plane) but I can figure that out and get back to you.

PROJCS["Google_Maps_Global_Mercator",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Mercator_2SP"],PARAMETER["standard_parallel_1",0],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",0],PARAMETER["false_easting",0],PARAMETER["false_northing",0],UNIT["Meter",1]]

Failed to install srs on ArchLinux due to python version

Hi,

I git issue when npm install srs on ArchLinux because the default python is already 3. The node-srs / tools / scons / scons.py script doesn't compatible with python3.

Traceback (most recent call last):
File "/home/sun/var/src/tilemill/node_modules/srs/tools/scons/scons.py", line 66, in
if os.environ.has_key("SCONS_LIB_DIR"):
AttributeError: '_Environ' object has no attribute 'has_key'

I strongly recommend you to change the shell bang to /usr/bin/env python2.

Incorrect proj4 returned

@springmeyer This is in relation to the following ticket in mapnik-omnivore: mapbox/mapnik-omnivore#31

From the convo we had in chat, doing an explicit gdalwarp from the source's projection (ESPG:2227) to WGS84 resulted in the correct extent and center. And verified that something is going on in node-srs.

@dnomadb suggested there could be some discrepancy between the units of the projection (feet vs. meters). How does node-srs handle units?

compile broken on freebsd

../deps/osr/src/cpl_conv.cpp:2464:21: error: variable has incomplete type 'VSIStatBufL' (aka 'stat64')
        VSIStatBufL sStatBuf;
                    ^
../deps/osr/src/cpl_vsi.h:159:16: note: forward declaration of 'stat64'
typedef struct VSI_STAT64_T VSIStatBufL;
               ^
../deps/unix-include/cpl_config.h:209:22: note: expanded from macro 'VSI_STAT64_T'
#define VSI_STAT64_T stat64
                     ^
1 error generated.
gmake: *** [Release/obj.target/osr/deps/osr/src/cpl_conv.o] Error 1

geojson.test.js GeoJSON no ext: TypeError: a: OGR Error type #1 problem occured importing from srs wkt: ESRI::./test/data/mystery-api.

[strk@gnash:/usr/src/cartodb/node-srs(master)] make test

geojson.test.js GeoJSON no ext: TypeError: a: OGR Error type #1 problem occured importing from srs wkt: ESRI::./test/data/mystery-api.

 at Object.parse (/home/src/cartodb/node-srs/lib/srs.js:166:26)
 at Test.fn (/home/src/cartodb/node-srs/test/geojson.test.js:21:25)
 at Test.runParallel (/usr/lib/node_modules/expresso/bin/expresso:959:10)
 at Test.run (/usr/lib/node_modules/expresso/bin/expresso:924:18)
 at next (/usr/lib/node_modules/expresso/bin/expresso:867:22)
 at Test.run (/usr/lib/node_modules/expresso/bin/expresso:925:13)
 at next (/usr/lib/node_modules/expresso/bin/expresso:867:22)
 at Test.run (/usr/lib/node_modules/expresso/bin/expresso:925:13)
 at next (/usr/lib/node_modules/expresso/bin/expresso:867:22)
 at Test.run (/usr/lib/node_modules/expresso/bin/expresso:925:13)


 Failures: 1

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.