[OSM-dev] osm2pgsql Windows build

Kai Krueger kakrueger at gmail.com
Thu Dec 13 16:57:21 GMT 2012


On 12/12/2012 11:01 AM, Dominik Perpeet wrote:
> Would anyone be interested in a current osm2pgsql Windows build (Win32 +
> x64, both with 32 bit id space)?
> In the near future I will link the zipped binary package on the wiki:
> http://wiki.openstreetmap.org/wiki/Osm2pgsql

Great, thank you.

It seems like osm2pgsql for windows used to be kept at 
http://tile.openstreetmap.org/osm2pgsql.zip and is still from 2010.

I wonder if your version can be put up as a replacement for this at the 
same location?

>
> I recently needed a Windows version of the program and had to compile
> it. Needless to say, it took me a rather large part of an evening to
> accomplish. ;-)

You managed to do it in a single evening?! Not too bad... ;-)

>
> Version: b31c660 (git, Oct 28, 2012)

Since then a bunch of checkins have happened to try and make it easier 
to build osm2pgsql on windows. Largely they were to try and move back 
from C99 to ansi C, so that osm2pgsql can be compiled with msvc.

This cleanup work isn't yet finished and the code still has C99 
constructs. Particularly the array initialisers haven't yet been 
converted, as not using C99 features reduce code readability and so I 
was wandering if there are better ways to achieve this.

Using MinGW or the Intel compiler seems to be one route? Coverting 
things to C++ might be another?

Any suggestions what the most sensible route is in general for the best 
portability?

> Built using:
>      - geos 3.3.5
>      - libxml 2.9.0
>      - pgsql 9.2.1
>      - proj 4.8.0
>      - proto_buf 0.1.5
>      - zlib 1.2.7
>
> NOT included:
>      - gazetteer
>      - shell prompt
>      - null output
>      - libgen
>      - pthread (obviously fork() doesn't work on windows and I didn't
> want to get into making the code thread-safe)

The current code now has a configure check to test if fork is available 
and if doesn't compile the multi-process code. I haven't looked at the 
advantages and disadvantages of OpenMP, but perhaps indeed that is an 
option. However, I suspect the big issue there are the connections to 
postgresql, as each thread / process needs to setup its own connections 
and transactions to postgresql.

>
> In order to compile the C99 code, I used the Intel Compiler. I
> successfully compiled Win32 and x64 versions and imported current osm
> planet pbf's. Mapnik rendering (current version) appears to work fine
> with the created databases.
> The rather extensive changes and inclusion of dependencies into a
> solution prevent me from committing the resulting source. If there is
> serious interest, I can cobble together a brief description of what I
> did and share my VS2010 solution.

Yes, I think there is serious interest in this. And if reasonably 
possible, I would like to get as many of those changes into the svn 
master repository as possible to make it easier to compile on windows in 
the future.

>
> Is anyone against switching to C++ (see osm2pgsql TODO)? In my opinion
> it would result in cleaner code and make building on windows a lot
> easier. Also, fork() could be replaced with omp if the effects are
> sorted out carefully.
>
> Dominik Perpeet

Kai



More information about the dev mailing list