mapbox / wellknown Goto Github PK

Hey,
I have a service which gives me wkt's with some whitespaces (Do not ask why..) .
After debugging the parse method, found that white() does not match the use case when there is a whitespace after the first '(' character.
Example:
LINESTRING ( 30 10, 10 30, 40 40)
It matches first two whitespaces, not matches the whitespace after '('.
Checked for other shapes as well.

Caveat: I am in the process of learning and setting up my first app using npm, grunt, browserify so this could be a noob issue:

Upon installing the wellknown module from npm, and requiring into my browserify project, I get an error when running Grunt that grunt-browserify cannot find the brfs module. Since your package.json specifies the brfs transform in the browserify options, I beleive either brfs should be in dependencies (rather than devDependencies) section of your package.json, or the browserify settings/transform should be removed. As a workaround, I simply installed brfs to my project and I no longer get the error.

The .substring(i) pattern is probably a performance hit - should look into other simple patterns for doing this, or look at a potential tokenize step.

The readme indicates 4d is supported, but it's actually not due to this part of the tuple regex:

'(\\s' + numberRegexp.source + ')?'

The last ? matches 0 or 1 times, meaning only 3 dimensions can be parsed. In fact, attempting to parse a EWKT string with 4 dimensions breaks the parser entirely.

stringify also does not support 4d:

  function pairWKT (c) {
    if (c.length === 2) {
      return c[0] + ' ' + c[1];
    } else if (c.length === 3) {
      return c[0] + ' ' + c[1] + ' ' + c[2];
    }
  }

Given the input from https://gist.github.com/perliedman/7216826, wellknown fails with a simple "null" as response:

$ cat geometrycollection.wkt | wellknown
null

Tested with wellknown 0.1.1 on Windows with Node 0.10.17.

The same WKT can be parsed by at least OpenLayer's WKT parser. Test it for example here: http://www.liedman.net/gis-nerd-tools/ - enter EPSG:3006 as coordinate system and paste the WKT. It displays properly (and in the correct location if you check the swap coordinates checkbox :)).

geometries like this return null from parse

GEOMETRYCOLLECTION(MULTIPOINT(1 2, 3 4), LINESTRING(5 6, 7 8))

this code here seems to cause a problem

Not sure if it's in the scope of this lib, but it currently accepts invalid point entries, which in turn makes it spit out invalid GeoJSON.

Sample input:

POLYGON(1,2,3)

results in:

{"type":"Polygon","coordinates":[[[1],[2],[3]]]}

From the PDF that shall not be mentioned, it appears that the grammar says a point must have at least x and y, possibly also z.

Those three strings, when parsed, result in a valid GeoJSON output:

MULTIPOLYGON(40 40,20 45,45 30,40 40)),((20 35,10 30,10 10,30 5,45 20,20 35)))
MULTIPOLYGON(((40 40,20 45,45 30,40 40))((20 35,10 30,10 10,30 5,45 20,20 35)))
MULTIPOLYGONN(((40 40,20 45,45 30,40 40)),((20 35,10 30,10 10,30 5,45 20,20 35)))

I'd expect a null instead.

Otherwise, in our use case, the invalid WKT passes the browser-side validation and makes it through to a Postgres/PostGIS DB. PostGIS then rejects anything like the three examples above.

I should switch these tests to tap.

Hi, all the packages published prior to July 22, 2016 have the package LICENSE file as WTFPL (which matches the LICENSE in the repo), while the metadata file (package.json says “BSD").

Question: what is the license for the NPM packages for v0.4.2 and earlier (1) WTFPL license, (2) “BSD” (BSD-3-Clause?) or (3) dual-licensed?

Thanks.

Ideally the coords parser should be self-contained and not rely on any () context.

Hey, i recognized that the version that is in npm and bower doesn't reflect the actual master version. But the version in the package.json is the same at master, npm and bower, all 0.2.0. So it should reflect the same state, i guess?!

POINT(0, 0) will not parse.

If you start with

const wkt = 'MULTIPOLYGON EMPTY'

and then try to roundtrip it using

const newWkt = stringify(parse(wkt))

you end up with MULTIPOLYGON (). which in turn parses to null (which cannot be stringified anymore).

So in summary:

• MULTIPOLYGON EMPTY parses just fine, to a geometry with empty coordinates array
• a multipolygon geometry with empty coordinates array stringifies to MULTIPOLYGON () instead of MULTIPOLYGON EMPTY, and is treated as invalid syntax when re-parsing it, resulting in a null parsing result

It's a little "cheap" to just dump the entire README markdown file when one runs the wellknown CLI command or even by specifying the --help option. I think it's not too much to ask to display a few helpful lines for well-rounded CLI usability, no?

wellknown('MULTIPOLYGON (((-74.03349399999999 40.688348)))')['coordinates']
[ [ [ -74.03349399999999, 40.688348 ] ] ]

this should be 4-deep (polygon is array of array of coord-arrays, multip is an array of those)

Hi, I needed to use your software with leaflet and in order to use it properly I had to delete some code surrounding the features.

Basically it was the first line and the last ones

Apparently via https://github.com/Esri/terraformer-wkt-parser/blob/master/spec/wktSpec.js WKT can have all kinds of things like EMPTY that I don't know about because there isn't a spec that I can read because the OGC is whiffing it so hard.

I'll implement fixes for things in the spec as soon as a spec is published in a web-accessible format. Until then, patches accepted. Call your OGC congressman, ask for HTML and to cut the jargon.

Parsing fails for WKT POINTS that have spaces directly after the open parenthesis and/or directly before the closing parenthesis. I haven't tested this issue on other types of geometry.

POINT ( -68.1712366598 -16.5122344611 4124.6247727228 )

var parse = require('wellknown'),
    geometry = parse('POINT ( -68.1712366598 -16.5122344611 )');
console.log(geometry);// geometry will be null