Opened 7 years ago

Closed 7 years ago

#4328 closed defect (invalid)

osm2pgsql produces empty LINESTRINGs on Mac OS

Reported by: openstreetmap@… Owned by: jburgess777@…
Priority: major Milestone:
Component: osm2pgsql Version:
Keywords: Cc:

Description

I've built osm2pgsql from svn (Revision 28156) on both my Mac OS (10.6.8) and a CentOS 6 machine. I've tried to make them as identical as is possible. Both are linked against geos 3.3.1 and proj 4.7.0.

gcc is 4.7.0 on Mac OS, and 4.4.6 on CentOS.

Example command-line: osm2pgsql --multi-geometry -d "gis" -p seattle_osm --slim -E 4326 -x --drop /tmp/Seattle.osm

When I run the command on Mac OS, the geometries produced for the lines table produces empty line strings. However, running the exact same command on my CentOS 6 machine produces the correct output. the points table is generated correctly, but I don't know about the polygons table, as I never get that far.

The input file is the same on both.

For example, on Mac OS, we get:

seattle_osm_line>>> -971480 \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N park \N \N \N \N Seward Park \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N 0 \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N "osm_version"=>"-1","osm_timestamp"=>"2012-03-16T08:16:40Z","website"=>"http://www.seattle.gov/Parks/environment/seward.htm" SRID=4326;LINESTRING ( , , )

but on CentOS we get:

seattle_osm_line>>> -971480 \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N park \N \N \N \N Seward Park \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N 0 \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N "osm_version"=>"-1","osm_timestamp"=>"2012-03-16T08:16:40Z","website"=>"http://www.seattle.gov/Parks/environment/seward.htm" SRID=4326;LINESTRING (-2.1299999999999999 0.8200000000000000, -2.1299999999999999 0.8300000000000000, -2.1299999999999999 0.8200000000000000)

as you can see, the right number of points is recognized (count the commas), but the actual coordinate values are missing.

I've spent some time tracking it down, I think the error is occurring in get_wkt_split().

Change History (4)

comment:1 Changed 7 years ago by jburgess777@…

Last time I managed to reproduce a problem like this it was due to multiple versions of Geos being installed. The trigger for the issue seems to be compiling the code (in particular build_geometry.cpp) with the geos header files from one version and then linking against a different version.

A simple fix is to make sure that you just only have the header files for the one version you want to use on your system. If you have copies in both /usr/include & /usr/local/include then which one you get depends on the ordering of the -I options.

comment:2 Changed 7 years ago by openstreetmap@…

Hmm.. I did find a copy of 3.3.0 hiding under /Library/Frameworks? (I think from Qgis), but I chmod'd that to make it inaccessible (and it wasn't included in the -I options anyway).

I made sure there were no other copies of the headers hanging out anywhere, and also made sure that the geos/version.h file (at least) matches what I expected to be installed.

The problem persists however.

I'm going to try this on a clean installed machine, just to double check you suspicion, but I feel pretty confident we're getting the right headers/library (unless gcc is doing some behind the scenes magic I'm not expecting.)

comment:3 Changed 7 years ago by jburgess777@…

Is your Geos library being built with the same compiler version? I believe C++ is not quite so stable between releases as the C ABI. If it was compiled with something different like LLVM then I have no idea what would happen.

comment:4 Changed 7 years ago by openstreetmap@…

Resolution: invalid
Status: newclosed

Hmm..

OK, rebuilding everything from source seems to have taken care of it.

I don't know who to hate more: c++, gcc, or MacPorts?.

Maybe I'll hate all three of them equally.

Note: See TracTickets for help on using tickets.