[OSM-dev] WMS API - where to start
hi all I'm working again on my map maplib. http://github.com/robotnic/khtmlib Internet Explorer should work now (exept vector graphics). The next thing I want to implement is WMS support. Implemetation should be easy. But I don't know how to design the API? Can somebody point me to a starting point? Bernhard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Retrieve Nearest Way
Hi Ian,
On Wed, Apr 14, 2010 at 11:27:37AM -0500, Ian Dees wrote:
I'm trying to write a mockup for simple editing tool and one of the steps
needed is to have a fairly quick find nearest way call. Can anyone
recommend some reading or pseudocode to find the nearest way given a
lat/lon?
The following is from my Leadme editor/project,
http://atterer.net/leadme. GPL v2 or v3. All coordinates are assumed to
be in a cartesian coordinate system, so you need to do a Mercator transform
first, and arguably the code will not find the nearest way in all cases
because of that - but it should be OK unless you edit a pole. It *is*
rather accurate in that it actually calculates the distance in 3D (not 2D),
and it also takes into account the (semi-)spheres around the endpoints of
each way segment.
Cheers,
Richard
const MapWay* Map::findNearestWay(const Point *p, double maxDistance,
double* dist) const {
double d = maxDistance;
const MapWay* result = 0;
for (Ways::const_iterator i = ways.begin(), e = ways.end(); i != e;
++i) {
//cerr Map::findNearestWay quickcheck *i d=
d endl;
if (i-nodes.size() 2)
continue; // Actually, such ways are forbidden
/* First create a bbox for the entire way, to quickly eliminate
* ways which are too far away. */
MapWay::Nodes::const_iterator j = i-nodes.begin(), je =
i-nodes.end();
double wayminx = (*j)-x, waymaxx = wayminx;
double wayminy = (*j)-y, waymaxy = wayminy;
while (++j != je) {
wayminx = min(wayminx, (*j)-x);
waymaxx = max(waymaxx, (*j)-x);
wayminy = min(wayminy, (*j)-y);
waymaxy = max(waymaxy, (*j)-y);
}
if (p-x + d wayminx || p-x - d waymaxx
|| p-y + d wayminy || p-y - d waymaxy)
continue;
//cerr Map::findNearestWay detailcheck *i d=
d endl;
/* Bboxes overlap - do the slow, accurate check. Calculate the
distance
* from each segment of the way. */
j = i-nodes.begin();
double dd = distance(*p, **j); /* Check half-sphere around
first node */
if (dd d) {
d = dd; result = *i;
//cerrnear 1st node d= d endl;
}
while (true) {
const MapNode* o = *j; // old node
++j;
if (j == je) break;
const MapNode* c = *j; // current node
/* t is the normalized direction vector of the way
segment */
double tx = c-x - o-x, ty = c-y - o-y, tz = c-z -
o-z;
double segmentLen = sqrt(tx*tx + ty*ty + tz*tz);
tx /= segmentLen; ty /= segmentLen; tz /= segmentLen;
/* projLen = length of projection of p onto the segment
o c */
double hesseDist = o-x * tx + o-y * ty + o-z * tz;
double projLen = p-x * tx + p-y * ty + p-z * tz -
hesseDist;
//cerrproj= projLen segment=
segmentLen endl;
if (projLen 0 || projLen segmentLen + d/2) continue;
if (projLen segmentLen) {
/* p may be inside half-sphere at endpoint c */
double dd = distance(*p, *c);
if (dd d) {
d = dd; result = *i;
//cerrnear n-th node, dd= dd
endl;
}
} else { /* or inside the cylinder around the segment */
double distpo = distance(*p, *o);
double dd = sqrt(distpo*distpo -
projLen*projLen);
if (dd d) {
d = dd; result = *i;
//cerrnear segment, dd= dd
endl;
}
}
}
}
if (result != 0 dist != 0)
*dist = d;
return result;
}
--
__ ,
| ) /| Richard Atterer | GnuPG key: 888354F7
| \/ | http://atterer.net | 08A9 7B7D 3D13 3EF2 3D25 D157 79E6 F6DC 8883
54F7
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Planet OSM 'bad result during COPY'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I've searched high and low for a solution to this problem and have found nothing that works. I have successfully imported a CloudMade extract of California into my PostGIS database and rendered tiles from it using the Mapnik scripts. Able to confirm basic functionality, I decided to move up to a full planet import. I have tried 3 planet files (100317, 100401 and 100407) with the same error at different points for each file and sometimes different places for the same file on different runs. No import is able to get past the nodes import. From searching on the forums it at first seemed the error was being caused by duplicate data in the Planet file and running without --slim would bypass the problem. Here is the latest run on the 100401 planet export without slim mode: - --- # md5sum planet-100401.osm.bz2 6c8b60c7e5c3de093521ba31f3c634cc planet-100401.osm.bz2 # cat planet-100401.osm.bz2.md5 6c8b60c7e5c3de093521ba31f3c634cc planet-100401.osm.bz2 # osm2pgsql --database world --username gis --password --verbose planet-100401.osm.bz2 osm2pgsql SVN version 0.69-exported Password: Using projection SRS 900913 (Spherical Mercator) Setting up table: planet_osm_point NOTICE: table planet_osm_point does not exist, skipping NOTICE: table planet_osm_point_tmp does not exist, skipping Setting up table: planet_osm_line NOTICE: table planet_osm_line does not exist, skipping NOTICE: table planet_osm_line_tmp does not exist, skipping Setting up table: planet_osm_polygon NOTICE: table planet_osm_polygon does not exist, skipping NOTICE: table planet_osm_polygon_tmp does not exist, skipping Setting up table: planet_osm_roads NOTICE: table planet_osm_roads does not exist, skipping NOTICE: table planet_osm_roads_tmp does not exist, skipping Mid: Ram, scale=100 Reading in file: planet-100401.osm.bz2 Processing: Node(61870k) Way(0k) Relation(0k)planet_osm_point - bad result during COPY, data 86767681 \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 \N Unterdürnbach \N \N \N \N \N \N village \N \N \N \N \N \N \N \N \N \N \N \N \N \N SRID=900913;POINT(1767106.17982627 6203496.15919218) Error occurred, cleaning up # - --- Running with slim mode on yields the same errors earlier in the document (around 32000k if memory serves) My installation is CentOS 5.4 with the latest SVN (20912) osm2pgsql. PostgreSQL 5.4.3 and postgis 1.3.6-1 were installed via Yum from the PGDG84 repository. Thanks in advance for any help. — Seth -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.12.0 (Build 1035) Charset: windows-1252 wsBVAwUBS8dik8gJWVul8LvVAQh4dQf/Y0JnlKur4WqiddieEBPs2AMtX0qB9j9b atBEQJgHVOIs4+DFiGohpYUDwi2mITt/CG2sLAOhMb4atrs7xF1dpP/74cZpIY8m blrieRzP7OENQuPSCQjkoQpoh3ktgUgchysf9MONqxDrEKVWFTTYmIz4KQkcnoXy RnWmmR6A3KYRlikAscZh9W9q1e+hOyCZhNTxRw4nSzdkUlHXONTwV1LuKMGN9r3s ypY8hUFXH9JMylVkpU51gZUc168VxE2YVhONdHC/fEUbainHhVy/8HaSUcG8A/U+ dWWps26Hnesskv5dxcv+Iakc6JrndGmICsMNNEPq8p23pXJzqZ+NNw== =JqEi -END PGP SIGNATURE- ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Planet OSM 'bad result during COPY'
Seth, just a hunch and it really shouldn't happen but is it possible that you have an issue with non-ascii characters (which are unlikely in the california extract but certain to exist in the world-wide data)? You could quickly try e.g. the Austria excerpt (which should contain the Unterdürnbach node that was listed in your report) to verify this. If Austria works then my hunch is wrong. Also, are you sure you have sufficient memory for running without --slim? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Planet OSM 'bad result during COPY'
I've downloaded the Austrian extract and have been running the import for a few minutes. I'll report back if it succeeds or fails. I should have plenty of RAM (a blade with 16GB available). I've seen a number of forum posts about using the -C (cache) flag during imports. How much does this actually help and what are some good metrics to use when setting the value? — Seth On Apr 15, 2010, at 12:21 PM, Frederik Ramm wrote: Seth, just a hunch and it really shouldn't happen but is it possible that you have an issue with non-ascii characters (which are unlikely in the california extract but certain to exist in the world-wide data)? You could quickly try e.g. the Austria excerpt (which should contain the Unterdürnbach node that was listed in your report) to verify this. If Austria works then my hunch is wrong. Also, are you sure you have sufficient memory for running without --slim? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 PGP.sig Description: PGP signature ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[josm-dev] How does priority setting work ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Sorry for setting priority of todays bug on blocker. Was wrong. I noticed that a lot of bug priorities were changed and I sometimes wonder why (maybe we should add a comment each time we change it). Please tell me your opinion. If a bug is blocking me from working me with latest but it is not present in tested, I consider it as a blocker. If a bug is destroying data I consider it as critical. Cheers Colliar -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREIAAYFAkvHbbsACgkQalWTFLzqsCtJGQCgtAvfaf6OWQxxrcnx9Gbo64xz h08An2rePEYSif3g54uULUlQRkI3l+uM =DhuR -END PGP SIGNATURE- ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Planet OSM 'bad result during COPY'
Hi A reasonable value for --cache is 4GB for a planet import. I don't think that 4GB will be reached but if your server has it.. Peter Seth Voltz schrieb: I've downloaded the Austrian extract and have been running the import for a few minutes. I'll report back if it succeeds or fails. I should have plenty of RAM (a blade with 16GB available). I've seen a number of forum posts about using the -C (cache) flag during imports. How much does this actually help and what are some good metrics to use when setting the value? — Seth * * On Apr 15, 2010, at 12:21 PM, Frederik Ramm wrote: Seth, just a hunch and it really shouldn't happen but is it possible that you have an issue with non-ascii characters (which are unlikely in the california extract but certain to exist in the world-wide data)? You could quickly try e.g. the Austria excerpt (which should contain the Unterdürnbach node that was listed in your report) to verify this. If Austria works then my hunch is wrong. Also, are you sure you have sufficient memory for running without --slim? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org mailto:frede...@remote.org ## N49°00'09 E008°23'33 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Planet OSM 'bad result during COPY'
On Thu, Apr 15, 2010 at 8:01 PM, Seth Voltz seth.vo...@shiftresearch.com wrote: My installation is CentOS 5.4 with the latest SVN (20912) osm2pgsql. PostgreSQL 5.4.3 and postgis 1.3.6-1 were installed via Yum from the PGDG84 repository. PostgreSQL 5.4.3? that seems awfully old. are you sure? cheers, matt ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Planet OSM 'bad result during COPY'
Matt Amos schrieb: On Thu, Apr 15, 2010 at 8:01 PM, Seth Voltz seth.vo...@shiftresearch.com wrote: My installation is CentOS 5.4 with the latest SVN (20912) osm2pgsql. PostgreSQL 5.4.3 and postgis 1.3.6-1 were installed via Yum from the PGDG84 repository. PostgreSQL 5.4.3? that seems awfully old. are you sure? CentOS doesn't do feature updates but rather support the same version for up to 10 years. This is good for business applications that get seployed once and never touched again but it is bad for the fast moving web-2.0-crowdsourcing-maps-and-wiki applications we love. maybe one of these repos have a newer postgres: http://dag.wieers.com/rpm/ or http://www.jasonlitka.com/yum-repository/. The first one is mentioned and the centos page [1] [1] http://centos.org/modules/smartfaq/faq.php?faqid=14 Peter cheers, matt ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] How does priority setting work ?
colliar colliar4e...@aol.com writes: Hi Sorry for setting priority of todays bug on blocker. Was wrong. I noticed that a lot of bug priorities were changed and I sometimes wonder why (maybe we should add a comment each time we change it). Please tell me your opinion. If a bug is blocking me from working me with latest but it is not present in tested, I consider it as a blocker. If a bug is destroying data I consider it as critical. A bug that blocks you from doing something might not be relevant to many other people. Also destroying data can mean different things. Just try to picture the relevance to the JOSM users in general and not only to your special case. Matthias ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Planet OSM 'bad result during COPY'
On Thu, 2010-04-15 at 12:01 -0700, Seth Voltz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I've searched high and low for a solution to this problem and have found nothing that works. I have successfully imported a CloudMade extract of California into my PostGIS database and rendered tiles from it using the Mapnik scripts. Able to confirm basic functionality, I decided to move up to a full planet import. I have tried 3 planet files (100317, 100401 and 100407) with the same error at different points for each file and sometimes different places for the same file on different runs. No import is able to get past the nodes import. From searching on the forums it at first seemed the error was being caused by duplicate data in the Planet file and running without --slim would bypass the problem. Here is the latest run on the 100401 planet export without slim mode: - --- Reading in file: planet-100401.osm.bz2 Processing: Node(61870k) Way(0k) Relation(0k)planet_osm_point - bad result during COPY, data 86767681 \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 \N Unterdürnbach \N \N \N \N \N \N village \N \N \N \N \N \N \N \N \N \N \N \N \N \N SRID=900913;POINT(1767106.17982627 6203496.15919218) Error occurred, cleaning up # - --- Running with slim mode on yields the same errors earlier in the document (around 32000k if memory serves) Odd, I don't think I have ever seen that error before. The presence of that ü in the output makes me wonder if this is an encoding issue. Your database using should be UTF-8: $ psql -l List of databases Name| Owner | Encoding | Collation |Ctype| Access privileges ---+--+--+-+-+--- gis | jburgess | UTF8 | en_GB.UTF-8 | en_GB.UTF-8 | If it is not UTF-8 then you will need to create it again, e.g. $ createdb -E UTF8 -O username gis If that does not work then perhaps you should look in the postgresql server log to see if that includes a more verbose error message. Jon My installation is CentOS 5.4 with the latest SVN (20912) osm2pgsql. PostgreSQL 5.4.3 and postgis 1.3.6-1 were installed via Yum from the PGDG84 repository. Thanks in advance for any help. — Seth ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Planet OSM 'bad result during COPY'
Jon and Frederik: good hunch, the Austrian import failed with: # osm2pgsql --database world --username gis --password --verbose austria.osm.bz2 ... (cut) ... Reading in file: austria.osm.bz2 Processing: Node(6760k) Way(0k) Relation(0k)planet_osm_point - bad result during COPY, data 430058975 \N \N \N \N \N \N \N \N \N \N \N \N \N \ N \N \N \N \N \N \N \N bus_stop \N \N \N \N \N \N \N \N \N \N \N Altöttinger Straße/Aldi \N \N \ N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N SRID=900913;POINT(1398018.41536173 6112460.23312236) ... (cut) ... I double checked the database: everything, including my GIS templates and the working database are UTF8: # psql -U gis -l ... (cut) ... world| gis | UTF8 | en_US.UTF-8 | en_US.UTF-8 | Also, I just noticed that when it fails it also crashes the whole PostgreSQL server requiring a `service postgresql restart` to get going again. This started when I began using the --verbose switch. Failed imports with and without --slim and without --verbose just fail but leave the database alone. The log file in /var/log/pgsql is empty (0 bytes). Matt Peter: good catch, it was a typo. I have 8.4.3 from the pgdg84 repository which I setup with: # rpm -ivh http://yum.pgsqlrpms.org/reporpms/8.4/pgdg-centos-8.4-2.noarch.rpm — Seth Seth Voltz | CTO | Shift Inc. seth.vo...@shiftresearch.com | www.shiftresearch.com voice: (774) 262-9092 _ This email and any attachments thereto may contain private, confidential, and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto. On Apr 15, 2010, at 1:49 PM, Jon Burgess wrote: On Thu, 2010-04-15 at 12:01 -0700, Seth Voltz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I've searched high and low for a solution to this problem and have found nothing that works. I have successfully imported a CloudMade extract of California into my PostGIS database and rendered tiles from it using the Mapnik scripts. Able to confirm basic functionality, I decided to move up to a full planet import. I have tried 3 planet files (100317, 100401 and 100407) with the same error at different points for each file and sometimes different places for the same file on different runs. No import is able to get past the nodes import. From searching on the forums it at first seemed the error was being caused by duplicate data in the Planet file and running without --slim would bypass the problem. Here is the latest run on the 100401 planet export without slim mode: - --- Reading in file: planet-100401.osm.bz2 Processing: Node(61870k) Way(0k) Relation(0k)planet_osm_point - bad result during COPY, data 86767681 \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 \N Unterdürnbach \N \N \N \N \N \N village \N \N \N \N \N \N \N \N \N \N \N \N \N \N SRID=900913;POINT(1767106.17982627 6203496.15919218) Error occurred, cleaning up # - --- Running with slim mode on yields the same errors earlier in the document (around 32000k if memory serves) Odd, I don't think I have ever seen that error before. The presence of that ü in the output makes me wonder if this is an encoding issue. Your database using should be UTF-8: $ psql -l List of databases Name| Owner | Encoding | Collation |Ctype| Access privileges ---+--+--+-+-+--- gis | jburgess | UTF8 | en_GB.UTF-8 | en_GB.UTF-8 | If it is not UTF-8 then you will need to create it again, e.g. $ createdb -E UTF8 -O username gis If that does not work then perhaps you should look in the postgresql server log to see if that includes a more verbose error message. Jon
Re: [OSM-dev] Planet OSM 'bad result during COPY'
On Thu, 2010-04-15 at 14:24 -0700, Seth Voltz wrote: Jon and Frederik: good hunch, the Austrian import failed with: # osm2pgsql --database world --username gis --password --verbose austria.osm.bz2 ... (cut) ... Reading in file: austria.osm.bz2 Processing: Node(6760k) Way(0k) Relation(0k)planet_osm_point - bad result during COPY, data 430058975 \N \N \N \N \N \N \N \N \N \N \N \N \N \ N \N \N \N \N \N \N \N bus_stop\N \N \N \N \N \N \N \N \N \N \N Altöttinger Straße/Aldi \N \N \ N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N SRID=900913;POINT(1398018.41536173 6112460.23312236) ... (cut) ... I double checked the database: everything, including my GIS templates and the working database are UTF8: # psql -U gis -l ... (cut) ... world| gis | UTF8 | en_US.UTF-8 | en_US.UTF-8 | Also, I just noticed that when it fails it also crashes the whole PostgreSQL server requiring a `service postgresql restart` to get going again. This started when I began using the --verbose switch. Failed imports with and without --slim and without --verbose just fail but leave the database alone. Anything which crashes the database backend sounds more like an issue in Postgresql rather than osm2pgsql. One thing you might want to try is to recompile osm2pgsql against the PostgreSQL-8.4 client library. There is a good chance that a binary built in the normal way will be linking against the standard system library (probably /usr/lib/libpq.so.4) not the postgresql-8.4 (probably libpq.5 somewhere). To find out the library it is using try: $ ldd ~/bin/osm2pgsql | grep libpq libpq.so.5 = /usr/lib64/libpq.so.5 (0x7f6311499000) The above output is from a F-12 system using PostgreSQL-8.4.3 You will need to install the pgdg postgresql-devel package and maybe tweak the include path in the Makefile to pick up the right version when you recompile. The log file in /var/log/pgsql is empty (0 bytes). Matt Peter: good catch, it was a typo. I have 8.4.3 from the pgdg84 repository which I setup with: # rpm -ivh http://yum.pgsqlrpms.org/reporpms/8.4/pgdg-centos-8.4-2.noarch.rpm — Seth Seth Voltz | CTO | Shift Inc. seth.vo...@shiftresearch.com | www.shiftresearch.com voice: (774) 262-9092 _ This email and any attachments thereto may contain private, confidential, and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto. On Apr 15, 2010, at 1:49 PM, Jon Burgess wrote: On Thu, 2010-04-15 at 12:01 -0700, Seth Voltz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I've searched high and low for a solution to this problem and have found nothing that works. I have successfully imported a CloudMade extract of California into my PostGIS database and rendered tiles from it using the Mapnik scripts. Able to confirm basic functionality, I decided to move up to a full planet import. I have tried 3 planet files (100317, 100401 and 100407) with the same error at different points for each file and sometimes different places for the same file on different runs. No import is able to get past the nodes import. From searching on the forums it at first seemed the error was being caused by duplicate data in the Planet file and running without --slim would bypass the problem. Here is the latest run on the 100401 planet export without slim mode: - --- Reading in file: planet-100401.osm.bz2 Processing: Node(61870k) Way(0k) Relation(0k)planet_osm_point - bad result during COPY, data 86767681 \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 \N Unterdürnbach \N \N \N \N \N \N village \N \N \N \N \N \N \N \N \N \N \N \N \N \N SRID=900913;POINT(1767106.17982627 6203496.15919218) Error
Re: [OSM-dev] Planet OSM 'bad result during COPY'
Definitely worth checking out. When I setup the system I didn't install any of the CentOS Postgres packages and instead relied on the pgdg84 available ones. --- # ldd /usr/local/bin/osm2pgsql | grep libpq libpq.so.5 = /usr/lib64/libpq.so.5 (0x2aab6b07c000) --- Now for the embarrassing part. While the machine I'm running on has 16GB of RAM it lives in a virtual machine and it received a RAM cap of 372MB. Whoops. After finding the right logs to check (/var/log/pgsql is a red herring and I have a non-standard data directory location) all the problems were being caused by *massive* swapping and eventual shared memory allocation errors which stacked up until postgres just gave up the ghost and couldn't auto recover any more. I asked our admin to bump me up to 8GB and the Austria import completed beautifully in only 6 minutes without even a hint of an error. As a comparison, it took 45 minutes before for Austria to fail. Postgres logs are clean as well. I have started the planet import with --slim turned back on and will write back with how it works. My apologies for having missed this one. Also, you guys are lightning quick on the draw with really helpful questions and replies. Your help has been much appreciated! — Seth P.S. In the time it took to write up this email and verify I haven't missed anything else, I've pulled in 4k points and eaten up 4GB of RAM. It's running quite a bit faster than I had expected. On Apr 15, 2010, at 2:49 PM, Jon Burgess wrote: On Thu, 2010-04-15 at 14:24 -0700, Seth Voltz wrote: Jon and Frederik: good hunch, the Austrian import failed with: # osm2pgsql --database world --username gis --password --verbose austria.osm.bz2 ... (cut) ... Reading in file: austria.osm.bz2 Processing: Node(6760k) Way(0k) Relation(0k)planet_osm_point - bad result during COPY, data 430058975 \N \N \N \N \N \N \N \N \N \N \N \N \N \ N \N \N \N \N \N \N \N bus_stop\N \N \N \N \N \N \N \N \N \N \N Altöttinger Straße/Aldi \N \N \ N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N \N SRID=900913;POINT(1398018.41536173 6112460.23312236) ... (cut) ... I double checked the database: everything, including my GIS templates and the working database are UTF8: # psql -U gis -l ... (cut) ... world| gis | UTF8 | en_US.UTF-8 | en_US.UTF-8 | Also, I just noticed that when it fails it also crashes the whole PostgreSQL server requiring a `service postgresql restart` to get going again. This started when I began using the --verbose switch. Failed imports with and without --slim and without --verbose just fail but leave the database alone. Anything which crashes the database backend sounds more like an issue in Postgresql rather than osm2pgsql. One thing you might want to try is to recompile osm2pgsql against the PostgreSQL-8.4 client library. There is a good chance that a binary built in the normal way will be linking against the standard system library (probably /usr/lib/libpq.so.4) not the postgresql-8.4 (probably libpq.5 somewhere). To find out the library it is using try: $ ldd ~/bin/osm2pgsql | grep libpq libpq.so.5 = /usr/lib64/libpq.so.5 (0x7f6311499000) The above output is from a F-12 system using PostgreSQL-8.4.3 You will need to install the pgdg postgresql-devel package and maybe tweak the include path in the Makefile to pick up the right version when you recompile. The log file in /var/log/pgsql is empty (0 bytes). Matt Peter: good catch, it was a typo. I have 8.4.3 from the pgdg84 repository which I setup with: # rpm -ivh http://yum.pgsqlrpms.org/reporpms/8.4/pgdg-centos-8.4-2.noarch.rpm — Seth PGP.sig Description: PGP signature ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] How does priority setting work ?
2010/4/15 Matthias Julius li...@julius-net.net: If a bug is blocking me from working me with latest but it is not present in tested, I consider it as a blocker. If a bug is destroying data I consider it as critical. A bug that blocks you from doing something might not be relevant to many other people. Also destroying data can mean different things. +1. I'd consider preventing from working far less dangerous than destroying data though: at least you can't do harm (and the bug will normally by fixed within short time, while destroyed data might not be noticed for quite some time, so the bug is more evil. cheers, Martin ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
