Fix for CYGWIN which resolves undefined references #9
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… objects. Fixes #2405. git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@19144 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
…extra-attributes option is off by default git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@19145 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@19147 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@19148 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@19281 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
…rcing tags (eg. missing building=yes) still show up in the polygon table. git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@19398 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@19407 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@19603 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@19604 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@19633 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
…ueries git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@19640 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
…r were unable to parse any valid columns git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@19974 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
… to Frans Hals) git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@20034 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
Tweaks to how house numbers are pressented. Fix json output (incorrect address details) git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@20035 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@20134 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@20149 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@20161 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@20163 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@20255 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@20369 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@20370 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@20418 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@20429 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
At least in theory this will allow for 3-column output tables now. Tested with the following environment: * non slim mode * hstore-new (http://pgfoundry.org/projects/hstore-new/ * PgSQL 8.4/PostGIS 1.4 git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@20475 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@20493 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
…s well git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@20505 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
where no additional tag columns should be added. For this reason we introduce a new flag called phstore which will do the same as the polygon flag but without adding a column for the tag specified in the stylefile. git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@20565 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
the reason is, that hstore rows can get really long, thus dynamic allocation prevents them to get cut and (hopefully) also prevents likely buffer overflows as well. git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@20775 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@20802 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
as 3GB of virtual address space. This is due to 3GB/1GB split on 32bit linux machines. No matter how much physical RAM you have, you end up on 3GB limit. This is quite low limit when importing anything big as country OSM file or the whole planet OSM. If we know this, we should warn user in syntax help, during runtime and even when we start throwing std::bad_alloc during conversion. git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@20823 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
…ays at once. For the postgresql back-end this issues all way requests of a relation in a single sql call and then matches the result back to the list of ways in osm2pgsql. This saves round trip time / context switches to postgresql and potentially allows postgresql to be more efficient in retrieving the data. On tests with small extracts, this nearly doubled performance of the relation processing stage and showed increases of up to 25% for the complete import. On larger imports this speedup is likely smaller, but hopefully still noticeable. This function currently does not yet combine loading of nodes from multiple ways in ways_get_list, which might in future provide additional speed up. git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@28747 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@28748 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@28761 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@28788 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
…32bit platforms to sparse Chunked and optimized both cause problems on platforms with limited virtual memory (i.e. 32bit platforms), so change the default to sparse, which doesn't have as much virtual memory overhead for accounting and indexing. git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@28789 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
In an attempt to get osm2pgsql compiled for windows, move back to using ANSI C standard, as msvc doesn't support C99. Also clean up some compiler warnings. git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@28862 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
…cceed In multi-process mode, if the fork did not succeed "Iterate over pending ways" and "Iterate over pending relations" produced the wrong data, as the fall back mechanism didn't correctly work. The information of the reduced number of successful helper processes was only conveyed to the first process, and therefore all other helper processes used the wrong stride length to go through the pending ways/relations array. Therefore many ways/relations were not correctly processed. Using a mmaped structure, make sure all helper processes know how many processes correctly started for processing. git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@28864 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
The function index() is deprecated in the posix standard and superseded by the strchr function. As index is not available in MinGW, replace it with strchr to make osm2pgsql compile. git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@28865 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@28868 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
This is a patch provided by http://wiki.openstreetmap.org/wiki/Osm2pgsql/o5m and improved by Darafei Praliaskouski git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@28876 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
This is a set of commits by Darafei Praliaskouski with some own changes Unless the --exclude-invalid-polygon flag is given, all invalid geometries are fixed using the buffer(0) method git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@28877 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
This is a patch by Darafei Praliaskouski git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@28878 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
This is a patch by Darafei Praliaskouski git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@28879 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
…pported ones This is a patch by Darafei Praliaskouski git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@28880 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@28907 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
… warning with clang++ git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@28908 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@28948 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
A number of files used in osm2pgsql can be bigger than 4Gb so we need large file support such that off_t is 64bit. Try and use a more portable version to enable large file support through compiler preprocessor directives git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@28956 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@28957 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@28958 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
…SO C90 forbids mixing declarations and code - another step toward supporting -ansi -pedantic git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@28959 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
git-svn-id: http://svn.openstreetmap.org/applications/utils/export/osm2pgsql@28960 b9d5c4c9-76e1-0310-9c85-f3177eceb1e4
|
please rebase or re-issue a pull request as per #11 (comment) |
|
could you re-create this pull? Also, would be good to know why you think this fix is needed? |
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If building under cygwin, you'll encounter the following undefined references:
build_geometry.o: In function
coords2nodes': /cygdrive/c/development/bamboo/bamboo-home/xml-data/build-dir/OSM-OSM2PSQL-JOB1/build_geometry.cpp:220: undefined reference togeos::geom::Coordinate::Coordinate(double, double, double)'/cygdrive/c/development/bamboo/bamboo-home/xml-data/build-dir/OSM-OSM2PSQL-JOB1/build_geometry.cpp:220: undefined reference to
geos::geom::Coordinate::~Coordinate()' /cygdrive/c/development/bamboo/bamboo-home/xml-data/build-dir/OSM-OSM2PSQL-JOB1/build_geometry.cpp:220: undefined reference togeos::geom::Coordinate::~Coordinate()'This update resolves those issues.