Re: [OSM-dev-fr] Polygon de la France
J'ai essayé les deux scripts pour créer le polygon de la France et : (...) Je ne les ais pas encore utilisé, mais sachant qu'ils ont été plus ou moins écrit dans ce but, je suis surpris que ça ne marche pas. Est-ce que ce n'est pas tout simplement car la france actuellement, ne forme pas un polygone fermé ? Je me souviens que j'en avais eu besoin il y a environ 1 an, et je n'avais pas eu de problème. D'ailleurs j'ai toujours dans ma base postgis la france métropolitaine : (http://sly.letuffe.org/osm/france.sql) Elle ne doit plus être tout à fait à jour, mais ça me suffit encore pour tout mes traitements, les frontières n'ayant pas bougé tant que ça ;-) -- sly qui suis-je : http://sly.letuffe.org ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Polygon de la France
En fait pour le moment je ne cherche pas à importer mais à extraire la France avec le completeWays et completePolygon à yes. La commande était : osmosis --read-pbf file=europe.pbf --bounding-polygon file=france.poly completeWays=yes completRelations=yes --write-pbf file=france.pbf Mais avec le fichier france.poly de cloudmade, ça m'a donné un fichier pbf de 1.6Go, ce qui me semble cohérent. Oui ça m'intéresserait bien ton script :) Kin 2011/8/30 Jocelyn Jaubert jocelyn.jaub...@gmail.com 2011/8/29 Aurélien FILEZ kinj...@gmail.com: - mega-relation-analyser.py donne un fichier de polygon filter de 5.3Mo, qui semble être bien formatté mais l'import avec osmosis ne donne rien (fichier : 0k) Est-ce que tu n'aurais pas des soucis pour l'import juste à cause d'un mauvais format du fichier généré (ou des IDs qui ne collent pas) ? Quelle est la commande que tu utilises pour l'import osmosis ? Personnellement, j'utilise un autre script pour télécharger récursivement les relations et les importer dans une bdd osmosis. Je peux te l'envoyer si tu es intéressé. -- Jocelyn ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Polygon de la France
2011/8/30 Aurélien FILEZ kinj...@gmail.com: En fait pour le moment je ne cherche pas à importer mais à extraire la France avec le completeWays et completePolygon à yes. La commande était : osmosis --read-pbf file=europe.pbf --bounding-polygon file=france.poly completeWays=yes completRelations=yes --write-pbf file=france.pbf Mais avec le fichier france.poly de cloudmade, ça m'a donné un fichier pbf de 1.6Go, ce qui me semble cohérent. Il faut faire gaffe que le france.poly utilisé par geofabrik est un poil trop petit, et ne contient donc pas toute la frontière de la France. Je voulais renvoyer un nouveau .poly, mais je n'ai pas encore réussi à vérifier que le nouveau contient bien toute la relation de la France Métropolitaine. Je ne sais pas quel france.poly tu as utilisé, ni celui que utilise cloudmade. Oui ça m'intéresserait bien ton script :) Je l'ai mis sur: https://github.com/jocelynj/osm/tree/fb5d414618efdfe3e2b8ec9806a92035b476f4a9/tools Il faut juste configurer les différentes variables correctement dans le ../config, et lancer le script avec un: ./import-relation-to-osmosis.sh 1362232 # c'est le numéro de la relation France Métropolitaine. Le script télécharge un à un les relations nécessaires, les modifie en .osmchange, et les donne à manger à osmosis pour mettre à jour la base de donnée locale. -- Jocelyn ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev] Osmium - Saving nodes to memory, so they are accessible when processing ways?
On Mon, Aug 29, 2011 at 08:10:24PM +0200, Frederik Ramm wrote: mmap uses a file but acts as if it were direct-access memory, so your system must have a large enough address space. This has nothing to do with the amount of physical memory. And to clarify further: There are two different ways of using the mmap handler for storing node locations: One uses RAM only (if you initialize it without a filename), the other uses the disk as backing store (if initialized with a filename). Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM on BlackBerry
Thanks a lot for your messages! It seems that the best solution for me would be to set up an own tile server, download the tiles from OSM and then providing them to the users of our app. We have planned to let the app display maps offline, so a permanent data service wouldn't be necessary. @Toby: Styling our own tiles is a great idea. That way, we could provide the most appropriate map representation for our users. Is there a documentation on tile styling? On 25 August 2011 10:20, Peter Körner osm-li...@mazdermind.de wrote: Am 24.08.2011 21:01, schrieb Greg Troxel: http://wiki.openstreetmap.org/**wiki/Tile_usage_policyhttp://wiki.openstreetmap.org/wiki/Tile_usage_policy I have always found it odd that it seems acceptable for non-Free/Open_Source software to use tiles from osm servers. Am I really reading that correctly? Using tiles from osm.org is acceptable as it obeys the license requirements and does not create too much load on the tile server. Peter ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Osm2pgsql and failed planet import
Hi everyone, I've been attempting to perform a planet import for mapnik rendering for the past few weeks without success. I've setup my PostGreSQL database with PostGis correctly, including the various parameter tweaks. I setup PostGreSQL on a separate Windows Server 2008 box with 8GB RAM, in order to separate processes and not have osm2pgsql have missing memory issues. This box has plenty of space for the final database. I setup a virtual box on our virtualization server using a CentOS distribution, obtained osm2pgsql from source, turned on the 64bit compilation flags and compiled it. This virtual box has 16GB memory. I've attempted several times to import, without success. The last attempt I made was using a boundary box, hoping osm2pgsql would have an easier time just importing North America. I'm using slim mode and a 14GB cache. Here is the command line and the output: ./osm2pgsql64 -c -s -m -C 14000 --bbox -165,13,-45,90 -U gis -W -H 192.168.1.131 -P 5432 -S ./default.style ./planet-110810.osm.bz2 osm2pgsql SVN version 0.80.0 (64bit id space) Password: Using projection SRS 900913 (Spherical Mercator) Applying Bounding box: -165.00,13.00 to -45.00,90.00 Setting up table: planet_osm_point NOTICE: table planet_osm_point_tmp does not exist, skipping Setting up table: planet_osm_line NOTICE: table planet_osm_line_tmp does not exist, skipping Setting up table: planet_osm_polygon NOTICE: table planet_osm_polygon_tmp does not exist, skipping Setting up table: planet_osm_roads NOTICE: table planet_osm_roads_tmp does not exist, skipping Mid: pgsql, scale=100, cache=14000MB, maxblocks=1792001*8192 Setting up table: planet_osm_nodes NOTICE: table planet_osm_nodes does not exist, skipping NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index planet_osm_nodes_pkey for table planet_osm_nodes Setting up table: planet_osm_ways NOTICE: table planet_osm_ways does not exist, skipping NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index planet_osm_ways_pkey for table planet_osm_ways Setting up table: planet_osm_rels NOTICE: table planet_osm_rels does not exist, skipping NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index planet_osm_rels_pkey for table planet_osm_rels Reading in file: ./planet-110810.osm.bz2 Unknown node type 8 Processing: Node(1173423k) Way(104443k) Relation(1070274) parse time: 175361s Node stats: total(1173423751), max(1393174131) Way stats: total(104443727), max(125432779) Relation stats: total(1070274), max(1706327) Going over pending ways processing way (26160k)way_done failed: ERROR: out of memory DETAIL: Failed on request of size 419430400. (7) Arguments were: 75277817, Error occurred, cleaning up Now the error occurs with or without 64bits, with or without the boundary box. It seems like the pending ways section of the code is behaving oddly, or I've setup something incorrectly. The size of the memory request is odd as well. Anybody have any ideas? Best regards to all, Francisco -- View this message in context: http://gis.638310.n2.nabble.com/Osm2pgsql-and-failed-planet-import-tp6729516p6729516.html Sent from the Developer Discussion mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Osm2pgsql and failed planet import
On 27 August 2011 03:18, Francisco.Matamala francisco.matam...@weblakes.com wrote: Hi everyone, I've been attempting to perform a planet import for mapnik rendering for the past few weeks without success. I've setup my PostGreSQL database with PostGis correctly, including the various parameter tweaks. I setup PostGreSQL on a separate Windows Server 2008 box with 8GB RAM, in order to separate processes and not have osm2pgsql have missing memory issues. This box has plenty of space for the final database. I setup a virtual box on our virtualization server using a CentOS distribution, obtained osm2pgsql from source, turned on the 64bit compilation flags and compiled it. This virtual box has 16GB memory. osm2pgsql doesn't have any code to check for memory allocation failures and to deal with it in a sane way, it just assumes all allocations are fine until it checks the nodes when going over pending ways etc. Anthony posted a patch a couple of months back, I didn't hear if the patch was added to the svn version(s). ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Osm2pgsql and failed planet import
Hi, On 08/30/11 11:50, John Smith wrote: osm2pgsql doesn't have any code to check for memory allocation failures and to deal with it in a sane way The error message discussed here is not a segfault, but an out of memory condition reported by the PostgreSQL client library. It has nothing to do with osm2pgsql's own memory allocation. Bye Frederik ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OSM on BlackBerry
On 26 August 2011 11:23, Christian Anger christian.an...@runtastic.com wrote: Thanks a lot for your messages! It seems that the best solution for me would be to set up an own tile server, download the tiles from OSM and then providing them to the users of our app. We have planned to let the app display maps offline, so a permanent data service wouldn't be necessary. Downloading the full tileset and then serving it from your own place sounds like a good idea at first but it's quite impractical actually. The amount of data is such that it would become quite outdated before the download is finished, additionally the project's tileserver doesn't have a single file with all the tileset so it'd take billions of individual requests. So the popular options are to use an existing tileserver possibly with a tile cache on your server, or generate your own tiles as Toby explained. The link to the tile usage policy that people pasted only refers to OSM's own tileserver, and there are many more servers that render OSM data, that policy does not apply to them. But we have had a number of cases of abuse of the main tileserver and this is why everyone is sensitive about it. Still there are a number of mobile or web apps that use that server successfully and without running over the policy so don't be scared by it. I find it a little unfair that any usage of the existing free tileservers is immediately discouraged when someone asks about it, especially on IRC where a lot of potential users have been successfully scared away from OSM. As for a free existing blackberry library for showing the map I don't think it exists yet, unfortunately. Cheers ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] OSM Data to Distance Matrix
Good day, I am working on a project related to arc routing as a part of my undergraduate special problem. I wish to parse / convert the osm data file to a distance matrix. Are there existing libraries for converting osm data to distance matrix (or something close)? Thank you for reading the mail. Have a nice day. -- *James Carlo Plaras* BS Computer Science University of the Philippines - Los Baños ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Osm2pgsql and failed planet import
On 30 August 2011 12:07, Frederik Ramm frede...@remote.org wrote: Hi, On 08/30/11 11:50, John Smith wrote: osm2pgsql doesn't have any code to check for memory allocation failures and to deal with it in a sane way The error message discussed here is not a segfault, but an out of memory condition reported by the PostgreSQL client library. It has nothing to do with osm2pgsql's own memory allocation. This indicates the code should be changed to retrieve the data in blocks using a cursor. Mvg, -- Martijn van Oosterhout klep...@gmail.com http://svana.org/kleptog/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Osm2pgsql and failed planet import
I will look into the code that pre-allocates memory, this definitely sounds like a good idea. Out of curiosity, has anyone else reported problems with full planet imports lately? Thank you to everyone for their input and time. -- View this message in context: http://gis.638310.n2.nabble.com/Osm2pgsql-and-failed-planet-import-tp6729516p6743304.html Sent from the Developer Discussion mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Osm2pgsql and failed planet import
Hi, On 08/30/2011 07:43 PM, Martijn van O wrote: The error message discussed here is not a segfault, but an out of memory condition reported by the PostgreSQL client library. It has nothing to do with osm2pgsql's own memory allocation. This indicates the code should be changed to retrieve the data in blocks using a cursor. Yes, that would be fixing the symptom. But the heart of the problem seems to be (as you said yourself a while ago in this discussion) that the whole dirty mark scheme should not really be used during an initial import at all, or should it? I guess this needs some thorough investigation and I always hoped that someone more familar with that part of the code (hint, hint) would find the time to have a look ;) 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] OSM Data to Distance Matrix
Not sure I understand your request. If you want to do routing/distance calculation based on OSM road network, you'll find an excellent tool here: http://www.pgrouting.org/docs/tools/osm2pgrouting.html Mayeul Le mardi 30 août 2011 à 19:37 +0800, James Carlo Plaras a écrit : Good day, I am working on a project related to arc routing as a part of my undergraduate special problem. I wish to parse / convert the osm data file to a distance matrix. Are there existing libraries for converting osm data to distance matrix (or something close)? Thank you for reading the mail. Have a nice day. -- James Carlo Plaras BS Computer Science University of the Philippines - Los Baños ___ 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] OSM Data to Distance Matrix
I suggest you to look spatialite and some related tools. For example there is one for the routing, that start from osm data. http://www.gaia-gis.it/spatialite-2.4.0/Using-Routing.pdf On Tue, Aug 30, 2011 at 13:37, James Carlo Plaras jamespla...@gmail.com wrote: Good day, I am working on a project related to arc routing as a part of my undergraduate special problem. I wish to parse / convert the osm data file to a distance matrix. Are there existing libraries for converting osm data to distance matrix (or something close)? Thank you for reading the mail. Have a nice day. -- James Carlo Plaras BS Computer Science University of the Philippines - Los Baños ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev -- Maurizio Napo Napolitano http://de.straba.us ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Osm2pgsql and failed planet import
On 31 August 2011 02:44, Hartmut Holzgraefe hartmut.holzgra...@gmail.com wrote: i'm not aware of any other patch, but i changed the cache allocation http://lists.openstreetmap.org/pipermail/dev/2011-June/023002.html ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[josm-dev] Version 4327 is from 32nd of July.
the startpage shows this: 2011-07-32 (4327) Select and delete mode now have better visual indication what the next action will do (highlighting, cursor changes). can this be changed to 2011-08-21 ? Thanks, Martin ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Version 4327 is from 32nd of July.
On Tue, Aug 30, 2011 at 12:13:22PM +0200, Martin Koppenhoefer wrote: the startpage shows this: 2011-07-32 (4327) Select and delete mode now have better visual indication what the next action will do (highlighting, cursor changes). can this be changed to 2011-08-21 ? In the MySQL date arithmetics, it should be a funny way of writing 2011-08-01 :-) Marko ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Version 4327 is from 32nd of July.
On 08/30/2011 12:13 PM, Martin Koppenhoefer wrote: the startpage shows this: 2011-07-32 (4327) Select and delete mode now have better visual indication what the next action will do (highlighting, cursor changes). can this be changed to 2011-08-21 ? You can fix this yourself, it's a wiki. Cheers, Paul ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Version 4327 is from 32nd of July.
2011/8/30 Paul Hartmann phaau...@googlemail.com: You can fix this yourself, it's a wiki. thank you, I tried to but someone was faster... cheers, Martin ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
