In that case: merge object properties together? use object with highest version number?

My function looks like this, parsing data coming straight from the overpass api

geojson = osmtogeojson(JSON.parse(body), {
    flatProperties: true,
    uninterestingTags: {
        "highway": true,
        "maxspeed": true,
        "ref": true,
        "not:name": true,
        "not:name:note": true,
        "source": true,
        "alt_name": true,
        "note": true,
        "oneway": true
    }
});

The flatProperties seems to work but the tags listed there aren't stripped out, here is a sample from the output. Note highway and maxpseed are still present.

{
    "type": "Feature",
    "id": "way/5119284",
    "properties": {
        "highway": "residential",
        "maxspeed": "20 mph",
        "name": "St Pauls Road",
        "id": "way/5119284"
    },
    "geometry": {
        "type": "LineString",
        "coordinates": [
            [-1.0945502, 50.7943406],
            [-1.0947346, 50.7936904],
            [-1.0949974, 50.792788],
            [-1.0949348, 50.7926471],
            [-1.0945846, 50.7918164],
            [-1.0943593, 50.7914569],
            [-1.0944788, 50.7911133]
        ]
    }
}

Am I missing something? My goal is to try reduce the size of the geojson I am sending to the browser.

See

needs new parameter

When I use overpass turbo and export roads around my position as geojson I get every geometry.type as LineString.

However when I use this library and call the overpass API myself and convert I get them as Polygon

I'm using

geojson = osmtogeojson(JSON.parse(body), {
    "polygonFeatures": settings.polygonFeatures
});

where settings.polygonFeatures is the same as https://github.com/tyrasd/osmtogeojson/blob/gh-pages/polygon_features.json which is what overpass turbo uses according to https://wiki.openstreetmap.org/wiki/Overpass_turbo/Polygon_Features

What have I missed?

• list of breaking changes incl. how to upgrade
• deduplication callback #23
• pbf parsing (see #61)
• …

my osm file size is lager than 40G, so i need memory 200G ? is there any way to reduce the memory?

Hi there,
as complex Overpass requests resulting in a huge amount of features may have a big common feature type, it would be nice to whitelist keys during the conversion to GeoJSON.
Equivalent to the uninterestingTags parameter, there could be an interestingTags parameter which provides a list of allowed keys to the converter.
What do you think about that?

see mapbox/togeojson@1118c78

Hello,
I think it could be interesting to keep track of the nodes identifiers in OSM way-based features, for example by adding an array of nodes ID in feature properties. This would allow some advanced processing (like finding a door direction along a wall). Do you think it can be implemented ?

Add an id member of the feature objects containing its OSM type/id.

See tyrasd/overpass-turbo#182

another test case: http://overpass-turbo.eu/s/apQ

see http://wiki.openstreetmap.org/wiki/Tag:highway%3Delevator

For the outside ring, I usually advocate for counterclockwise (right hand rule) points, to mean a surface facing "up" (positive z).

see https://github.com/mapbox/tilemill/issues/2110

Hi,
I am trying to convert a big OSM file (shapes for France ~ 3 GB) to GeoJSON.

# node --max_old_space_size=100000 ../node_modules/osmtogeojson/osmtogeojson "boundaries/france-latest.osm.pbf" > "geojson/france-latest.osm.pbf.geojson"

However, I get the following error:

buffer.js:68
   const ui8 = new Uint8Array(size);
               ^

RangeError: Invalid typed array length
   at new Uint8Array (native)
   at createBuffer (buffer.js:68:17)
   at allocate (buffer.js:216:12)
   at Function.Buffer.allocUnsafe (buffer.js:176:10)
   at Function.Buffer.concat (buffer.js:354:23)
   at Object.module.exports [as join]
(/srv/sms/osm-rdf/node_modules/bops/join.js:6:12)
   at ConcatStream.getBody
(/srv/sms/osm-rdf/node_modules/concat-stream/index.js:37:42)
   at ConcatStream.end
(/srv/sms/osm-rdf/node_modules/concat-stream/index.js:42:29)
   at ReadStream.onend (_stream_readable.js:517:10)
   at ReadStream.g (events.js:286:16)

It works pretty well for my other shapefiles which have a size up to 2 GB. But this one gives me the error.
Do you have any idea how to fix it?

should be default for CLI tool. also see #4

Is it possible to upload this library to NuGet as well?

Hi,

I'm trying to get osm conversion to work, but I get the above error message with
let osmtogeojson = require('osmtogeojson');

I also tried
let osmtogeojson = require('osmtogeojson').default; and to use babel-plugin-add-module-exports as per this SO thread, but nothing seems to work.

Any further ideas on how to get this working? I'll happily provide more details

needs new parameter and auto-file-type-detection like here

trying to get the boundary / multipolygon of tel aviv, israel.
http://www.openstreetmap.org/api/0.6/relation/1382494

this is type boundary, tried also with the multipolygon version, got nothing

See this for a good test case: openstreetmap/openstreetmap-website#283

Is it expected that osmtogeojson will be processing this file for three hours and then crash with "FATAL ERROR: CALL_AND_RETRY_2 Allocation failed - process out of memory"? What is the maximal size of file safe to be processed?

I aquired the file from overpass API by visiting following URL (note that entire following line is an URL):

http://overpass-api.de/api/interpreter?data=(node(50,19.78,50.11,20.09);<;);out meta;

File processed with osmfilter, filtered to 28 MB is happily processed within 30 seconds.

When the file is too large, we got this error:

buffer.js:243
this.parent = new SlowBuffer(this.length);
^
RangeError: length > kMaxLength
at new Buffer (buffer.js:243:21)
at Function.Buffer.concat (buffer.js:501:16)
at Object.module.exports [as join](C:UsersMPHAppDataRoamingnpmnode_mo
dulesosmtogeojsonnode_modulesconcat-streamnode_modulesbopsjoin.js:6:12)
at ConcatStream.getBody (C:\Users\MPH\AppData\Roaming\npm\node_modules\osmto
geojson\node_modules\concat-stream\index.js:37:42)
at ConcatStream.end (C:\Users\MPH\AppData\Roaming\npm\node_modules\osmtogeoj
son\node_modules\concat-stream\index.js:42:29)
at onend (stream.js:66:10)
at EventEmitter.emit (events.js:126:20)
at afterRead (fs.js:1330:12)
at Object.wrapper as oncomplete

How to deal with this issue when it is not possible to split the file?

Switch to flat-properties (API) in next major release. See #51 (comment)

Here's a gist with a minimal test case: https://gist.github.com/mnquintana/2d7009ea406b6377269a?short_path=87290a1

1. I have a relation with two members, each of which is a way
2. OSM export includes both members and the relation that contains them

Expected

After parsing with osmtogeojson, there will be 3 features - two ways, and a relation.

Actual

After parsing with osmtogeojson (for the purposes of this example, done via overpass-turbo), there are only two features, each of which is associated with the relation, but the relation is not included as a feature.

• skeleton
• center
• bounds
• full

Currently, the ordering of the items in a relation can not be figured out anymore after the geojson-conversion. This should be possible as a relation is an ordered list.

The following link provides my code that gets all OSM alley elements in a map and that has a button to print all elements retrieved with overpass api.

https://stackoverflow.com/questions/30833825/send-only-selected-geojson-elements-in-leaflet

Instead retrieving all elements, I would like to me able to :

1. select multiple elements on my map (the selected elements would be marked with a different color then blue) by clicking on those I want.
2. print only the selected elements.

Any idea how to do this?

I hope this is ok to create an issue for a question...

Thanks so much!!

https://github.com/tyrasd/geojson-numeric

documentation of:

• produced GeoJSON structure
• conversion internals (polygon detection, multipolygons, ignored tags)
• API parameters, options (#4)

_convert2geoJSON @ index.js:782
_overpassJSON2geoJSON @ index.js:188
osmtogeojson @ index.js:44

Default npm install and I was processing overpass result set.
Webpack packaging. Browser Error. Ubuntu, Chrome Version 48.0.2564.97 (64-bit)

I assume I hit an unintended use case?

Well it will probably affect server side sooner or later...

Chrome V8 4.8.271.17
Node (v5.5.0) V8 4.6.85.31

from the source code:

            // TODO: this may not work in the following corner case:
            // a multipolygon amenity=xxx with outer line tagged amenity=yyy

Small issue; k is undefined here (index.js, line 458):

function build_meta_information(object) {
      var res = {
        "timestamp": object.timestamp,
        "version": object.version,
        "changeset": object.changeset,
        "user": object.user,
        "uid": object.uid
      };
      for (k in res)
        if (res[k] === undefined)
          delete res[k];
      return res;
}

Hi there,

I just stumbled upon this great project and tried to convert the following XML file:

https://gist.github.com/nambrot/10439781

and got the following output:

https://gist.github.com/nambrot/10439804

As you can see, Github properly displays it, but according to http://geojsonlint.com/, the GeoJSON is not valid since the first and last point are not equivalent. I'm not really familiar with the spec, so that's why I'm asking

jsperf shows no significant performance drawback. consider vanillifying.

log conversion process

• read in data
• parse (xml/json) data
• begin actual conversion
• intermediate steps?
• …

log errors and warnings such as

• missing node coordinates
• missing way node references
• missing way nodes
• missing relation member references
• missing relation members
• incomplete multipolygons
• missing multipolygon member roles
• unclosed multipolygon rings
• non-matching multipolygon rings
• tainted geometries
• eventually some more strict multipolygon checks
  • inner/outer intersection
  • touching inner/outer rings
  • self-overlappings of rings
• …

Hi great tool, but I've run into what seems like an arbitrary limitation/bug. I found two OSM Overpass output JSON files that differ by a single way with 4 nodes. The smaller one runs without failure. The larger one crashes consistently with:

FATAL ERROR: CALL_AND_RETRY_0 Allocation failed - process out of memory
Abort trap: 6

When the smaller file runs it requires less than 2GB of memory (out of ~15GB available).
The 1 way / 4 node difference is unremarkable, and is not the cause of the problem.

I know this because if I add space characters to the beginning of the smaller "good" file until it is the size of the larger file, it also fails with the above error. So this seems entirely about file size and not content. I have distilled it down to two files which contain the exact same JSON content (the good smaller file from above), but differ by the amount of leading whitespace added (about 240 bytes)

The file that is 268435577 bytes works, and the one that is 268435578 bytes (with one additional leading space character) fails. 256MB is 268435456 bytes, so these files are both slightly larger than that and maybe it's just a coincidence.

I'm running this on a Mac Mini with OS X 10.9.2 and 16GB of RAM. I'm using node.js version 10.26 installed from MacPorts. The osmtogeojson version is 2.0.4 and was installed from npm.

The "good" file can be obtained from Overpass with this command (assuming the OSM database doesn't change between now and when you try it):

curl -X POST -d '[out:json]; ( node(47.517358482056004,-122.44160651794401,47.728472517944,-122.240223482056); way(bn); rel(bw)["type"="multipolygon"];);( ._; way(r););( ._; node(r)->.x; node(w););out body qt;' http://overpass-api.de/api/interpreter > file.json

This command currently returns a file of 268435336 bytes. If you get more than that try pulling in the bounding box a tiny bit (6th decimal place) until it's less than this amount. That file should convert. Now add about 300 spaces to the beginning of the file until the size is about 268435600 bytes; that one should fail.

I've tried adding these v8 parameters to the node command to increase the memory it will allocate, but it doesn't help (I regularly run node scripts using these parms that consume 10+ GB of memory without any problems):

--max_new_space_size (max size of the new generation (in kBytes))
--max_old_space_size (max size of the old generation (in Mbytes))

Let me know if you need any more info.

Just spotted this question on OSM's help site:

https://help.openstreetmap.org/questions/48121/use-osmtogeojson-on-a-windows-commandline

Maybe it would be possible to add some info into the README to help Windows users who'll be stuck at "'npm' is not recognized as an internal or external command," (and even non-Windows users who don't have node.js installed).

Not a bug obviously - but definitely something that would be helpful.

If you have a query that can return duplicate records, then osmtogeojson will preserve them. Unfortunately, although it's not explicit in the GeoJSON spec, many consumers of GeoJSON (like CartoDB) expect a feature's identifier (id) property to be unique, and will fail if it isn't. It would be great if osmtogeojson would ensure that features are unique, so that users of the library don't have to.

I'm trying to covert a response from overpass to geojson and I want to know the bounding box of a relation. In current conversion I need to iterate on all features and group them by relation before I can do it... :-/

This is most needed when working with overlapping Polygons.

Possible sorting methods:

• by feature size (asc/desc)
• by OSM ID
• custom sorting functions
• …

Open questions:

• Let the base ordering (Polygons before Lines before Points) be changed by the user?

Is it easy to implement it in this library?

Thanks.

If the osm file is generated by JOSM, osmtogeojson will also include several other properties on each feature that aren't always necessary including:

• the timestamp (when object was last updated)
• version
• uid of last editor
• user name of last editor
• changeset (of last object edited)
• osm id of object.

Here's the same data:

• one exported via josm
• one exported via overpass

Would you think about including these in the uninteresting tags?
https://github.com/tyrasd/osmtogeojson/blob/2.0.0/index.js#L14

I don't know whether it would be as simple as adding these tags to the uninteresting tags list or not.

Hi, I am kind of confused since the cli tool and the browser script are supposed to convert overpass json to geojson right.
I just don't get any results when running this query:
http://overpass-api.de/api/interpreter?data=[out:json];way[%22piste:type%22](46.983414,10.198059,47.094289,10.38414);out;

and then converting to geojson via cli returns an empty feature set
osmtogeojson lopes.json > slopes.geojson
How is this supposed to work?

Let users define their own relation-geometry handlers (e.g. to support more relation types and/or to override built in functionality)?

• uninteresting tags
• polygon detection rules
• #6

The culprit is this line: https://github.com/tyrasd/osmtogeojson/blob/gh-pages/osmtogeojson#L54
Looks like a debugging print accidentally left in.