[OSM-dev-fr] question debutant sql + postgis
bonjour a tous, j'ai fait la requete suivante SELECT a.osm_id, a.name, count(*) FROM planet_osm_polygon AS a, planet_osm_polygon AS b WHERE a.admin_level='8' AND b.building = 'yes' AND ST_Contains(a.way, b.way)=True GROUP BY a.osm_id, a.name cela me renvoit l'erreur suivante NOTICE: TopologyException: side location conflict at 258193 6.21369e+06 - ? - un building avec erreur ? - comment le trouver ? merci d'avance didier ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] [OSM-talk-fr] Carte Gramin
Le 01/03/2012 19:05, sly (sylvain letuffe) a écrit : On jeudi 1 mars 2012, Yves wrote: Merci! J'ai d'ailleurs relance la generation, elled sont dispo directement dans Osmand (progressivement). Je m'associe aux autres bravos pour te remercier également de cette génération qui donne à osmand un profil tout de suite plus rando et devient un sympathique compagnon qui m'en ferait presque abandonner mon garmin. Avec les éloges vont aussi les yaka faucon ;-) C'est envisageable un prochain week end pluvieux de faire aussi une génération à partir des données ASTER, qui, dans nos alpes, sont plus précises que SRTM ? Cool, les conditions d'utilisations d'ASTER ont changé et on peut les télécharger via ftp avec un simple script, génial \o/. Bon, sinon pour les anarcho-libristes disposant d'une base postgis avec des courbes de niveaux issues d'Aster (mais juste pour faire du fitness, hein !), le script de génération pour Osmand est là: https://github.com/osmandapp/Osmand/tree/srtm-contour-V2/config/contours/V2 Il s'agit d'extraire un shapefile d'une base postgis à partir d'un .poly, d'en faire un .osm, et de le donner à OsmandMapCreator pour faire un .obf. Yves ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [Potlatch-dev] More UX testing
On 01/03/2012 17:41, Andy Allan wrote: I'm especially coming to the conclusion that defining the icons in map_features.xml is the wrong place to do it - the icons in the panel should always match the icons shown in the stylesheet. No idea how to fix that though :-) That's pretty easy in theory though I'm not necessarily offering to code it this evening! a) Take the tags defined for this feature in map_features.xml b) Construct an object with those tags, and run it through RuleSet.getStyles c) In the resulting StyleList, find a PointStyle, and extract the icon d) PROFIT etc. etc. cheers Richard ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [OSM-dev] osm2pgsql patch for nested relations
Darafei Praliaskouski m...@komzpa.net wrote: I am not using route= relations in osm2pgsql. Is there a way to skip their processing, to get more speed than 4 relations/sec? You could just skip the code following if( strcmp(type, route) == 0 ) in output-pgsql.c, but I doubt that this will increase your processing speed significantly because most of the hard processing work is for multipolygons relations anyway. Regards Sven -- If you continue running Windows, your system may become unstable. (Windows 95 BSOD) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Using custom renderer with mod_tile
Skye Book skye.b...@gmail.com wrote: Thanks for the clear explanation.. That meshes well with what I understood from reading the wiki and cursory looks at source code http://wiki.openstreetmap.org/wiki/Tirex/Overview has a nice diagram about how the different modules communicate. It is possible to run different backends in parallel. Sven -- How to prevent Java from forking? Use a spoon. (Found on http://slashdot.org) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql patch for nested relations
Le jeudi 1 mars 2012 11:30:03, Sven Geggus a écrit : You could just skip the code following if( strcmp(type, route) == 0 ) in output-pgsql.c, but I doubt that this will increase your processing speed significantly because most of the hard processing work is for multipolygons relations anyway. Reading that thread, I remembered that I don't need type=route either, I've commented that part of osm2pgsql but the speed gain is hardly noticeable (if at all) -- sly (sylvain letuffe) ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Nested relations and generic implementation of geometry constructs - Was :osm2pgsql patch for nested relations
I know that there are precedents, but I am highly averse to coding specific relation types into osm2pgsql. So do I, as you mentionned below, the problem is not osm2pgsql specific, but will need work in every tool to maintain support for ever changing relation's way of tagging, and every new relation types making it hard to have generic processing. Unfortunelty, that problems comes from what's in the database and the fact that several relation proposals exists with different meannings and different tagging structures. By meannings I mean that some relations are made to build a bigger geometry (type=multipolygon is one), some to records facts unreleated to geometry (i.e type=restriction ) The question is how do we improve that, while keeping free tagging system ? We are having a discussion about type=waterway relation here : http://wiki.openstreetmap.org/wiki/Talk:Relations/Proposed/Waterway in the generic vs specific relation constructs. Those favoring specific relation tagging have raised valid concerns about how hard it will be for mappers to enter nested relations and/or generic geometry building relations. But as a data consumer and algorithm maker, it might become a nightmare to support all types of roles and logic behind those. one is pushing the geometry up, the other is pushing the tags down. I guess both would be needed depending on what was the purpose of the relation. When the parent relation doesn't describe a geomety, but is a way to factor tags (name, ref, ...) maybe we need to push the tags down. When the parent relation makes a big geometry made of several child relation having a part of the geometry, that's the opposite. (country boundaries made of several linear boundaries comes to mind type=boundary_segment) -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql patch for nested relations
sly (sylvain letuffe) li...@letuffe.org wrote: Reading that thread, I remembered that I don't need type=route either, I've commented that part of osm2pgsql but the speed gain is hardly noticeable (if at all) Quite in contrast to multipolygon relations, there is almost no computation in route relations, their member ways are just added to the planet_osm_lines table, they are not even concatenated. Sven -- Microsoft ist offenbar die einzige Firma, die in der Lage ist, ein mit Office nicht kompatibles Bürosoftwarepaket einzuführen. (Florian Weimer in de.alt.sysadmin.recovery) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql patch for nested relations
their member ways are just added to the planet_osm_lines table, they are not even concatenated. Sven Are you sure ? I might be mistaken, but thought they were concatenated and then split again if in exces of 1°x1° (line ~1080 in output-pgsql.c ) I haven't fully checked what does the build_geometry function however, but I do remember that I got full geometries if I changed the split_at to 360° -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] release of full-history extracts
Hi I generated a new charge of history extracts, based on the 120213 full history dump. They have been created from the latest full-experimental-dump [1] using my history splitter [2], based on Jochen Topfs really great osmium framework [3]. They contain multiple versions of an object. If you just want the map-data as it is today, use the Geofabrik-Extracts [4]. The extracts can be downloaded from a server of my employer: http://osm.personalwerk.de/history-extracts/ Their size ranges from very small (a village) via medium (Berlin) to large (Germany), touching various countries. They only cover a very, very small part of the world and are currently targeted at application developers that are looking for data to test their history analysis apps. Most extracts are delivered as .osh.pbf files, readable with all history-enabled pbf parsers (eg. osmium). Some extracts are also available in the .osh.bz2 format (xml-basesd). Some common programs like JOSM can open them them when you rename them to .osm, but the produced output is not very useful in most cases. In contrast to the last set of extracts, the new ones are now cuttet using the softcut algorithm [6] using simple bounding-boxes [5]. Dumps created using that algorithm have the following characteristics: - ways are complete (as they are in the api-database) - ways are reference-complete (all referenced points are included) - relations are complete (as they are in the api-database) - relations are NOT reference-complete (relations may reference ways or nodes that are not in the extract) - relations referring to relations that come later in the file are included - all versions of an object of which one version touched the bbox are included Those files can eg. be used to create nice animations of your home-town like this: http://mazdermind.github.com/osm-history-renderer/karlsruhe.html Take a look at the Tutorial to see how it goes: https://github.com/MaZderMind/osm-history-renderer/blob/master/TUTORIAL.md As always, I first created a .pbf version of the full-planet file, which can be downloaded, too: http://osm.personalwerk.de/full-experimental-pbf/full-planet-120213-1231.osh.pbf Peter [1] http://planet.osm.org/full-experimental/full-planet-120213-1231.osm.bz2 [2] https://github.com/MaZderMind/osm-history-splitter [3] https://github.com/joto/osmium/ [4] http://download.geofabrik.de/ [5] http://osm.personalwerk.de/history-extracts/split.config [6] https://github.com/MaZderMind/osm-history-splitter/blob/master/softcut.hpp ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Soliciting feedback on conflation plugin
On Thu, Mar 1, 2012 at 9:13 AM, Josh Doe j...@joshdoe.com wrote: On Thu, Mar 1, 2012 at 9:00 AM, Mike N nice...@att.net wrote: On 3/1/2012 6:59 AM, Josh Doe wrote: Last night I checked in a minimally-functional (and definitely experimental) conflation plugin, appropriately called conflation. I re-downloaded the list of plugins in JOSM, but it doesn't show up there. Is the Jar file available somewhere? Yes, I mentioned this in the wiki; I think the plugin list isn't being updated during the current stabilization phase. You can download the JAR directly here: http://trac.openstreetmap.org/browser/applications/editors/josm/dist/conflation.jar One thing I forgot to mention is that you'll need to update utilsplugin2 to the latest version, as I had to make some changes in there. Just run Update plugins in Preferences. Note there are some limitations, such as you cannot replace an un-uploaded way with an un-uploaded way or an uploaded way with an uploaded way (one needs to be uploaded, the other not). I've mostly been testing this with nodes and ways. Read the wiki for more issues that need to be addressed, but this is certainly on the list. -Josh ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] osm2pgsql patch for nested relations
On 1-3-2012 15:28, Sven Geggus wrote: Quite in contrast to multipolygon relations, there is almost no computation in route relations, their member ways are just added to the planet_osm_lines table, they are not even concatenated. They are concatenated, up to a maximum length. Still, that's still a lot less work than multipolygon calculations. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Toronto Hack Weekend - Countdown
The Toronto Hack Weekend is coming up in two weeks. It's going to be pretty darn good. We've got a super venue, with tons of space and rock solid wifi; The Ryerson University Geography department is hosting us. Should you join us in Toronto? Absolutely. Sign up on the wiki now. http://wiki.openstreetmap.org/wiki/Toronto_Hack_Weekend_March_2012 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Re-importing the Planet
I've got an OSM tile server based on the Ubuntu instructions that I've been running and updating with Minutely Mapnik for over a month now. I just noticed that southern Australia has issues like incomplete roads, lack of large rivers, no green spaces, and no city labels. I have no idea how or when that happened, but any hints would be welcome. But that's not really the question. What I'd like to do is re-import the latest planet definition that I'm about 4 hours away from completely downloading. Can I just use the same osm2pgsql import command that I did originally or do I need to do something special to the gis PostGreSQL database that's been updated for a month? And if I do just the original import, will the old and new maps try to fit in the database concurrently until the import is done (about doubling the DB size), or does the current data go away as soon as the new import starts? I've not seen any instructions on how to do such a thing, so answers or links would be most welcome. Lynn (D) - KJ4ERJ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[josm-dev] Soliciting feedback on conflation plugin
Last night I checked in a minimally-functional (and definitely experimental) conflation plugin, appropriately called conflation. You can read more about it here: http://wiki.openstreetmap.org/wiki/JOSM/Plugins/Conflation There's certainly a lot of work to do, but it's actually functional enough to automatically create candidate matches between two selections, showing allowing you to run the Replace Geometry command. This is already usable for merging say GNIS nodes with area features. On the wiki page I've got a lot of ideas that I'd like to implement, but before proceeding any further I wanted to see what others think, both about the current design, direction, and what is most important to implement first. Thanks, -Josh ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Soliciting feedback on conflation plugin
On Thu, Mar 1, 2012 at 9:00 AM, Mike N nice...@att.net wrote: On 3/1/2012 6:59 AM, Josh Doe wrote: Last night I checked in a minimally-functional (and definitely experimental) conflation plugin, appropriately called conflation. I re-downloaded the list of plugins in JOSM, but it doesn't show up there. Is the Jar file available somewhere? Yes, I mentioned this in the wiki; I think the plugin list isn't being updated during the current stabilization phase. You can download the JAR directly here: http://trac.openstreetmap.org/browser/applications/editors/josm/dist/conflation.jar -Josh ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Soliciting feedback on conflation plugin
On Thu, 1 Mar 2012, Josh Doe wrote: I re-downloaded the list of plugins in JOSM, but it doesn't show up there. Is the Jar file available somewhere? Yes, I mentioned this in the wiki; I think the plugin list isn't being updated during the current stabilization phase. You can download the People should not assume such things. Better would have been to report that cron-job was broken. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
