Talk:Osmconvert

From OpenStreetMap Wiki
Jump to: navigation, search

Discuss osmconvert here:


drop brokenrefs

--drop-brokenrefs Ist diese Option auch für splitter/mkgmap notwendig? --chris66 11:02, 28 August 2011 (BST)

Hallo, das ist gut möglich, aber ich weiß es nicht sicher. Hast du es mal ohne diese Option probiert? Kommen dann Fehlermeldungen in splitter bzw. mkgmap? --Marqqs 18:45, 28 January 2012 (UTC)

Bounding box

The syntax of the bounding box is different, even if I use --emulate-osmosis. So mkgmap cannot use this information.

osmosis writes:

<bound box="53.80000,10.50000,54.00000,10.60000" origin="0.40.1"/>

osmfilter writes:

<bounds minlat="53.8" minlon="10.5" maxlat="54." maxlon="10.6"/>

--Brogo 14:31, 25 January 2012 (UTC)

Yes, you're right, osmconvert resp. osmfilter did not write Osmosis conform bounding boxes. Please try osmconvert version 0.5Z and osmfilter version 1.2L. --Marqqs 18:45, 28 January 2012 (UTC)

Problems with -180° longitude in polygon

Hi, when filtering data using a polygon (option -B=alaska.poly) the points having longitude -180° are missing. The example poly file for testing looks like

alaska
1
   -1.80000E+02 7.150000E+01
   -1.80000E+02 7.200000E+01
   -1.79990E+02 7.200000E+01
   -1.79990E+02 7.150000E+01
   -1.80000E+02 7.150000E+01
END
END

The same problem exists in osmosis but it is possible to use the workaround by defining longitudes smaller than -180°. So when using the following poly file the -180° longitude points are included in the result with osmosis but not with osmconvert.

alaska
1
   -1.80500E+02 7.150000E+01
   -1.80500E+02 7.200000E+01
   -1.79990E+02 7.200000E+01
   -1.79990E+02 7.150000E+01
   -1.80500E+02 7.150000E+01
END
END

Is there a workaround for osmconvert to include the -180° longitude points? I need them because the boundary of alaska uses some of them.

Thanks! --WanMil 22:52, 27 June 2012 (BST)

Hi WanMil, I just opened the source file and searched for "180". It seems that the plausibility checks might accept values > -180.1. Please try -180.05. If this does not work, try the -b option instead of the -B option. --Marqqs 23:08, 3 July 2012 (BST)
Thanks, -180.05 works. --WanMil 18:25, 4 July 2012 (BST)

PBF seems to be incorrect with --drop-author

Hi Marqqs,

I have another topic regarding PBF creation.

Using the option --drop-author the PBF is not readable by osmosis but by osmconvert. I have asked on the osmosis list. Could you please read yourself Igor Podolskiys answer (http://lists.openstreetmap.org/pipermail/osmosis-dev/2012-July/001296.html) and have a look if the osmconvert code is correct?

Thanks! --WanMil 07:38, 5 July 2012 (BST)

Hi Marqqs, is there any chance that you have a look on it? --WanMil 18:35, 14 September 2012 (BST)
Hi WanMil, thanks for this reminder! --drop-author simply excludes excludes the PBF objects uid and user_sid whereas --drop-version excludes version, timestamp, changeset, uid and user_sid. I am not sure why Osmosis cannot read --drop-author files. What about --drop-version files? Can Osmosis read them? --Marqqs 12:11, 15 September 2012 (BST)
Hi Marqqs, I've tried osmosis 0.41. A pbf file converted with --drop-version can be read without problems by osmosis. The same input file converted with --drop-author cannot be read by osmosis and creates an exception. --WanMil 12:28, 7 October 2012 (BST)

all-to-nodes

Finally got round to testing out osmconvert. I like the "all-to-nodes" feature (Osmconvert#Dispose of Ways and Relations and Convert them to Nodes). It works! except it seems to leave behind loads of untagged nodes (The nodes which used to be part of ways) -- Harry Wood 02:30, 4 September 2012 (BST)

Hello Harry, thanks. :-) However, the option "--all-to-nodes" should not delete any nodes. If it does, I would suspect a bug in osmconvert. Do you have an example or an example OSM file? --Marqqs 17:59, 5 September 2012 (BST)
Yeah so it's not deleting the nodes after it gets rid of the ways which use them. I was expecting that it would. Fair enough not to I suppose, but maybe it could be an option. Or the obvious follow up question is...
How to do this as a separate step? Is there an easy method of dropping untagged nodes as a .osm file operation? Couldn't actually see how to do this even within osmosis tag filtering options
-- Harry Wood 14:48, 6 September 2012 (BST)
OK, you want to delete untagged nodes (that's a different thing than to delete all nodes which are members of ways). Probably you might use osmfilter for this purpose, but I am not sure what options you would have to state, resp. if the program osmfilter would have to be extended for this task. Please try this:   grep -v "<node .*/>"
If this works too slow for your toolchain, please let me know, I will care for an alternative solution. --Marqqs 18:27, 7 September 2012 (BST)

no polygon file or too large

I obtain this errors for some poly files for large countries like USA or Russia but also for countries with a lot of islands like Indonesia or canada. Is it possible to fix? or the only solution is to simplify the files?

Thanks Luca

Hi Luca, to get fast memory initialization the number of edges in a border polygon is limited to a constant value (60,000 at present). Can you please tell me how many lines the largest of your polygon files contains? Maybe the easiest way is to rise this constant a bit... --Marqqs 18:27, 7 September 2012 (BST)
Hi Markus, sorry for my late answer my bigger file is about 120K line, it is the boundary file for USA. How could I solve the problem of lines at least on my private copy? Thanks --Lucadelu 8:07, 2 October 2012 (UTC)
That's a huge border file indeed! Most extract algorithms would run faster if you could shrink this border file. However, osmconvert will be able to process the huge border polygon file if you change the constant "border__edge_M" from 60004 to 130000. --Marqqs 13:31, 3 October 2012 (BST)

Following this principle, is to be built from osmconvert already using constant "border__edge_M" from 130000? For my poly lowering of Brazil's OSM has 72000 points. I saw that has some tips to compile for Linux, but to win 64 did not find anything

Error for .osm files with BOM

Be aware that osmconvert throws "unknown file format" error for .osm files which have BOM (Byte-order mark) bytes at the very beginning. (Please fix this bug!)

Hi User:Vecepapir, there are .osm files which start with 0xfe 0xff, and therefore osmconvert should ignore these two bytes? This can be done of course. What programs did create these files? --Marqqs 18:48, 16 October 2012 (BST)
Hi, no not ignored, used in order to interpret the file as big or little Indian, see the article on [Wikipedia] for details. Probably important if the file is in UTF-16 or so.

--Nospam2005 (talk) 10:31, 17 October 2015 (UTC)

all-to-nodes

First let me say thank you for Osmconvert, it works great. Right now the all-to-nodes feature sets the node's latitude and longitude to the way's geographical center. Is there an easy way to modify the code so it takes the latitude and longitude of the first node instead? If this is too difficult, I can offer a payment via paypal. --25 November 2012 (EST)

Hello and thanks! However, the program is open source and it's free of charge. Please use it and enjoy! :-) You are right, osmconvert takes the center as geoposition of the newly created node. But – only for closed ways. If a way is not closed, the program takes one of the nodes to represent the position of the way. When I programmed the --all-to-node option, I figured that this would be reasonable for streets, railways, etc. --Marqqs 21:54, 25 November 2012 (UTC)
Thanks for the quick response. Doing it that way for streets and railways is reasonable, but I am looking for Hiking trails and the first node in the way is the most important. I took a look at the code and I don't feel comfortable modifying it myself, I can hire someone else to make the changes but you wrote it and know it best. I can offer you payment to make this modification if you are willing.
To just take the first node is not that difficult, however, is the first node always the node which starts the trail? Maybe it's the last node of the way? What if a trail is made of several ways which are combined by a relation? --Marqqs 11:04, 26 November 2012 (UTC)
I understand that my method of taking the first node is not flawless, but it would be correct at least some of the time as opposed to never the way it currently works.
Hello again! Please try to sign your Wiki messages with --~~~~ at the end (this will be replaced by user name and date). Concerning the first-node problem: I have just prepared the source file accordingly. Please download it (version 0.7K), search for the text "uncomment to use first node of each way" (should be around line number 10050), remove the first "//" (left of "break;") and compile it, e.g. this way: "gcc osmconvert.c -lz -O3 -o osmconvert". I hope it works... :-) --Marqqs 16:09, 27 November 2012 (UTC)
Awesome, thanks so much, it works great! --Kingdee40 01:40, 28 November 2012 (UTC)

Complete-ways and complex-ways options in dummy-use?

Hello Marqqs, and thanks for Osmconvert! I'm using it (or trying) in dummy-mode because I cannot manage other command-line tools. Would there be possible to access the complete-ways and complex-ways options in this mode? --JB (talk) 15:16, 28 June 2013 (UTC)

Hi JB, thanks for your suggestion! I just added --complete-ways and --complex-ways to the interactive mode ("Bert"). Please download version 0.7T and try functions 3a, 3b, 4a or 4b. --Marqqs (talk) 10:08, 30 June 2013 (UTC)


osmconvert loosing tags in conversion

I have just observed the following problem with latest version of osmconvert:

  • convert osm XML file to PBF. The XML does not have metadata (user, version, timestamp). Runs with no error message.
  • convert PBF back to XML file. Runs with no error messages.

The output has fake metadata (version=1, changeset=1, etc...) and every tagged node has only one tag, regardless of how many tags there were originally. It seems to be the last tag. All others are lost. --Nop (talk) 10:04, 7 July 2013 (UTC)

Hi Nop, thanks for your error report! Unfortunately I did not manage to reproduce the error. Do you have an .osm file I could experiment with? --Marqqs (talk) 11:01, 28 July 2013 (UTC)

Osmconvert ubuntu 12.04 output file has ? at the end and is not OK

I am new to linux, so please bare with me :)

consider script file a.sh:

header of bash

./osmconvert map.pbf -o=map2.osm

./osmfilter map2.osm --drop-node-tags="source" -o=map3.osm

If the 2 commands are run separately in the terminal, or piped or 1 command at a time in script, everything is ok

./osmconvert map.pbf -o=map2.osm | ./osmfilter map2.osm --drop-node-tags="source" -o=map3.osm

but if both commands are run in script map2.osm has ? at end of the file and can't be red.

So the question is what am I doing wrong, or how do I run many commands of osmconvert or osmfilter in a script?

I have found a temporary solution, to put a pipe at the end of each line, but not sure why it works.

Dan

If so, I dont think that at least lon min is correct.


$ osmconvert germany.osm.pbf --out-statistics timestamp min: 2005-07-05T02:14:17Z timestamp max: 2011-07-31T19:59:46Z lon min: -20.0712330 lon max: 21.1441799 lat min: 47.0830289 lat max: 59.9982830 nodes: 78138447 ways: 11342322 relations: 176024 node id min: 1 node id max: 1380816490 way id min: 92 way id max: 123952798 relation id min: 159 relation id max: 1693098

Looks right to me. Could be a sea cable or something like that. --Marqqs (talk) 17:31, 8 August 2014 (UTC)
Maybe an indication in the help explaining that relations/ways can go beyond a (multi)polygon limit would make sense. Nothing to do with the great tool osmconvert but with the planet filtering but as osmconvert makes it obvious... And then remove this paragraph. --Nospam2005 (talk) 07:00, 19 October 2015 (UTC)

--out-osh does not return deleted ways (visible=false)

Please refer to this github ticket for more details: Github

Mmd (talk) 06:04, 13 June 2014 (UTC)

14 reading o5m files larger than 2GB on windows

Is it possible to read o5m files larger that 2 GB? Cannot get this to work. I'm using 64 bit Windows 7 and osmconvert.exe binary provided from the link on the wiki page.

If possible, could someone please compile a Windows version that don't have this limitation?

Using this command: osmconvert z10x529y338_largecut.o5m -b=5.9365625,51.79577752045249,6.368125,52.09249047600099 --complex-ways --drop-author -o=z10x529y338.osm

I'm getting this error: osmconvert Error: could not rewind file: z10x529y338_largecut.o5m

The source file is 2,25 GB.

Are you sure that you have enough free space on your harddrive for any tempfile needed + result file? --Stephan75 (talk) 18:59, 6 August 2014 (UTC)
Did you check using the 64 bit work-around below? If it works, please update this section (including my answer ;-)) --Nospam2005 (talk) 21:25, 15 December 2015 (UTC)

64bit version of osmconvert for Linux

Hello,

I am wondering if anyone has been able to or can direct me as to how to get or compile a 64 bit version of the binary for Linux. I have been integrating this into a web app and would like to host it with a provider with whom I do not have root access and cant install the necessary 32bit libraries for the currently offered version. Any help or guidance greatly appreciated.

Thanks, Aaron

Hi Aaron, I compiled a 64-bit version for you, available here: http://edwardbetts.com/tmp/osm/osmconvert Edward (talk)
Thanks! Super! --Boombaxter (talk) 02:02, 31 January 2015 (UTC)

64bit version for Windows?

(was a question from Christian, he was running out of space using a 32 bit version on Windows).

An workaround is to install VirtualBox then Vagrant: For instance use an Ubuntu 12.04 LTS (i.e a precise box) and run sudo ./init.sh from [1].

A native 64bit Version for Windows would be fine cause integrating a Linux box into the tool-chain is a little bit complicated - however, its working.

osmconvert Error: node nanodegrees must be 100: 10000

I had tryed a lot of different things but i still get the same error

mapuser@map-analyst:~$ osmconvert planet-latest.osm.pbf.6 --pbf-granularity=100 -o=planet-latest.o5m osmconvert Error: unrecognized option: --pbf-granularity=100 mapuser@map-analyst:~$ osmconvert planet-latest.osm.pbf.6 --pbf-granularity=100 -o=planet-latest.o5m osmconvert Error: unrecognized option: --pbf-granularity=100 mapuser@map-analyst:~$ osmconvert planet-latest.osm.pbf.6 --pbf-granularity= 100 -o=planet-latest.o5m osmconvert Error: unrecognized option: --pbf-granularity= mapuser@map-analyst:~$ osmconvert planet-latest.osm.pbf.6 -o=planet-latest.o5m osmconvert Error: node nanodegrees must be 100: 10000 mapuser@map-analyst:~$ osmconvert --pbf-granularity=100 planet-latest.osm.pbf.6 -o=planet-latest.o5m osmconvert Error: unrecognized option: --pbf-granularity=100 mapuser@map-analyst:~$ osmconvert planet-latest.osm.pbf.6 --pbf-granularity=10000 -o=planet-latest.o5m osmconvert Error: unrecognized option: --pbf-granularity=10000


osmconvert Error: unrecognized option: --pbf-granularity=10000 mapuser@map-analyst:~$ osmconvert planet-latest.osm.pbf.6 -o=planet-latest.o5m --verbose osmconvert: Verbose mode. osmconvert Error: node nanodegrees must be 100: 10000 osmconvert: Last processed: node 105562. osmconvert Exit: 1121

I have found the error, i need a new version of osmconvert I have osmconvert 0.7T on the ubuntu system