You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.
Reporter: openstreetmap[at]darrell.pub.garnix.org [Submitted to the original trac issue database at 10.08am, Tuesday, 27th March 2012]
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.
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.
Author: jburgess777[at]googlemail.com [Added to the original trac issue at 8.34pm, Tuesday, 27th March 2012]
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.
Author: openstreetmap[at]darrell.pub.garnix.org [Added to the original trac issue at 9.10pm, Tuesday, 27th March 2012]
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.)
Author: jburgess777[at]googlemail.com [Added to the original trac issue at 9.19pm, Tuesday, 27th March 2012]
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.
Reporter: openstreetmap[at]darrell.pub.garnix.org
[Submitted to the original trac issue database at 10.08am, Tuesday, 27th March 2012]
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().
The text was updated successfully, but these errors were encountered: