Re: [OSM-dev] WG: Problem with Planet File Import
Hi, i also have svn version of osm2pgsql. Right now I'm trying to import Planetfile again. I gave osm2pgsql 2048 MB on cmd. But it is on round about 4 GB by going over pending ways. With postgis it is on 6 of 8 GB hop it will work this time. Importing takes realy long time. Best regards Stefan -Ursprüngliche Nachricht- Von: M∡rtin Koppenhoefer [mailto:dieterdre...@gmail.com] Gesendet: Dienstag, 31. Mai 2011 17:43 An: Stefan Menzel Betreff: Re: [OSM-dev] WG: Problem with Planet File Import 2011/5/29 Stefan Menzel menzel_ste...@gmx.de: Hello, the cmdln is nohup ./osm2pgsql -S default.style --slim -d gis -C 4096 /home/bin/smenzel/planet/planet-110504.osm.bz2 out7.txt How can I find out, which version osm2pgsql is installed? osm2pgsql --version cheers, Martin ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] legitimate IP blocked
https://twitter.com/#!/batje/status/76956988948496384 Uganda mapping party doing lots of good work today, got IP blocked. They have a workaround but shouldn't have to. I'm asking which IP, in case it's not obvious. == Mikel Maron == +14152835207 @mikel s:mikelmaron ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] legitimate IP blocked
On 04/06/11 15:55, Mikel Maron wrote: https://twitter.com/#!/batje/status/76956988948496384 https://twitter.com/#%21/batje/status/76956988948496384 Uganda mapping party doing lots of good work today, got IP blocked. They have a workaround but shouldn't have to. I'm asking which IP, in case it's not obvious. There's not much I can do anyway - we don't really have any way to override the limit. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql: missing osm_polygon and osm_line data under PostgreSQL 9/PostGIS 1.5.2
Hi Jon, Thank you for your work. We have SVN Revision no. r24100 of osm2pgsql installed. While still trying to resolve an out-of-memory issue with osm2pgsql in slim-mode we realized that the error output goes to the usual log output. It would be very helpful to print the error to it's separate error output stream in order to find more easily what's gonig wrong. Yours, Stefan 2011/5/6 Jon Burgess jburgess...@gmail.com: On Fri, 2011-05-06 at 20:23 +0200, Stefan Keller wrote: Hi, We recently upgraded to PostgreSQL 9 and PostGIS 1.5.2 and hence were forced to rebuild osm2pgsql because of new versions of its dependencies (e.g., libgeos). Afterwards, we tried to insert Switzerland data with the following command: $ osm2pgsql --create --database gisdb --prefix osm --style /usr/local/share/osm2pgsql/default.style --username xxx --hstore-all switzerland.osm.bz2 Unfortunately, only the osm_point table was filled with data, osm_polygon and osm_line were empty. This was not the case before the upgrade of the mentioned components. In the thread http://forum.openstreetmap.org/viewtopic.php?id=10725 somebody explained that this could be caused by multiple installations of libgeos or due to old installations of this library which is silently ignored by osm2pgsql and hence the tables will just not be filled. On our machine, I verified that this is NOT the case: $ ldd /usr/local/bin/osm2pgsql | grep libgeos libgeos-3.2.2.so = /usr/lib/libgeos-3.2.2.so (0x7f8485065000) As one can see, there is only one version of the shared library that is used and that one has the version we need. Do you have any ideas what the problem could be? I encountered the same problem when doing a similar upgrade yesterday. I managed to resolve it but I have not gone back to figure out exactly what causes it. The machine originally had both the system geos library in /usr and a custom compiled one in /usr/local. To resolve the problem I made sure I erased all traces of the system geos library and header files. Then did a 'make clean make' cycle and it started working correctly. I did a few steps to try to figure out where it was going wrong and identified that the getSize() call in build_geometry.cpp is always returning 0. This causes all of the line polygons geometries to be discarded. I have a suspicion this is triggered when using the headers from one version of geos and then linking against a different library version but I can not prove this yet. Jon ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql: missing osm_polygon and osm_line data under PostgreSQL 9/PostGIS 1.5.2
On Sun, 2011-06-05 at 01:23 +0200, Stefan Keller wrote: Hi Jon, Thank you for your work. We have SVN Revision no. r24100 of osm2pgsql installed. While still trying to resolve an out-of-memory issue with osm2pgsql in slim-mode we realized that the error output goes to the usual log output. It would be very helpful to print the error to it's separate error output stream in order to find more easily what's gonig wrong. Yours, Stefan Can you identify what message is being sent to STDOUT instead of STDERR? From a quick scan of the source the only ones I see going to stdout seem to be the help text, version number and bounding box information. All of the rest of the information, including all errors should already be going to stderr. Jon ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] legitimate IP blocked
Mikel Maron wrote: Uganda mapping party doing lots of good work today, got IP blocked. Others have reported similar problems[1], and I'd suspect that a number of mapping parts will hit the same issue as it is probably fairly common to proxy a whole network through a single IP. Furthermore, even individual mappers have reported hitting the IP limit when mapping with P2. I presume that the issue is the bandwidth throttling code in cgi_map, which was implemented to prevent people and applications from scraping large areas from the API instead of using planet extracts. It is implemented as a leaky bucket style throttling code per IP address, storing the amount of draw from the bucket in memcached. It is perhaps somewhat of an ugly hack, but would probably be fairly easy to implement and hopefully alleviate the issue somewhat. Would it be possible to stick a line into the diff upload controller in the rails_port that resets the bytes sent counter for the given IP in memcached every time someone uploads something? This way mappers who upload things would have much more leeway with the bandwidth limit than scrapers who only download. Kai [1] http://help.openstreetmap.org/questions/5438/how-to-avoid-potlatch-2-download-limit-when-editing-on-multiple-computers-on-a-network -- View this message in context: http://gis.638310.n2.nabble.com/legitimate-IP-blocked-tp6439322p6441104.html Sent from the Developer Discussion mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
