Re: [OSM-dev] Relation member_roles from Osmosis import
Common. There are many, many broken multipolygon relations. See http://tools.geofabrik.de/osmi/debug.html?view=multipolygonlon=13.04883lat=44.58577zoom=5 Whatever you do with OSM data you have to take into account that its not perfect and work around that. Jochen On Thu, Oct 28, 2010 at 02:48:12PM +0200, Frank Broniewski wrote: Date: Thu, 28 Oct 2010 14:48:12 +0200 From: Frank Broniewski b...@metrico.lu To: Jochen Topf joc...@remote.org CC: dev@openstreetmap.org Subject: Re: [OSM-dev] Relation member_roles from Osmosis import Hello Jochen, thanks for your answer, that makes it clear. I have another question about relations. I found a relation, a lake in Germany, (id=1104680, Schweriner See (Außensee)), which has serveral inner relations to ways. Some of these ways form a closed ways, so it's easy to create a polygon from it. But other ways with the relation role inner are not closed, but they form together an island in the lake. Should't those form a relation of themselves before relating them to the lake relation with an inner relation? The ways I am speaking of are 24563810 70191810 70191809 70191807 Luckily those ways form an island but if there would be another island formed by ways without relating them together it is quite difficult to recreate them properly. Is this situation an exception or is this a common situation? Frank Am 27.10.2010 11:01, schrieb Jochen Topf: On Wed, Oct 27, 2010 at 10:39:38AM +0200, Frank Broniewski wrote: During my examinations from an OSM import (osmosis pbf to postgis) I found some strange looking entries in the relation_members table. My goal is to make (GIS) polygons from the linestrings table and therefore I examined the relations a little closer. Doing a select distinct relation_id, member_role from relation_members I find these entries in the result, which I suspect to be wrong relation_id, member_role 22852;forward_stop_0 22852;forward_stop_11 22852;forward_stop_19 22852;forward_stop_9 22852;stop_1 22852;stop_10 22852;stop_12 22852;stop_13 22852;stop_14 300710;backward_stop_%n 207675;forward_stop_%n I think that numbering the member_role is not the intended way ;-) Thats a left-over from the time when relation members were not ordered. Jochen -- Frank BRONIEWSKI METRICO s.à r.l. géomètres technologies d'information géographique rue des Romains 36 L-5433 NIEDERDONVEN tél.: +352 26 74 94 - 28 fax.: +352 26 74 94 99 http://www.metrico.lu -- 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] Relation member_roles from Osmosis import
Cool, thanks for sharing the link, I didn't knew it. It's really helpful. I know that the data in OpenStreetMap may have issues - my questions simply arrive while I explore the osmosis import in my postgis database. And I'm one of the issues myself :D because I still learning the OpenStreetMap data format. But seeing the discussion that arose from my question concerning relations and super relations and such this still seems to be an evolving area ... Many thanks Frank Am 29.10.2010 10:14, schrieb Jochen Topf: Common. There are many, many broken multipolygon relations. See http://tools.geofabrik.de/osmi/debug.html?view=multipolygonlon=13.04883lat=44.58577zoom=5 Whatever you do with OSM data you have to take into account that its not perfect and work around that. Jochen On Thu, Oct 28, 2010 at 02:48:12PM +0200, Frank Broniewski wrote: Date: Thu, 28 Oct 2010 14:48:12 +0200 From: Frank Broniewskib...@metrico.lu To: Jochen Topfjoc...@remote.org CC: dev@openstreetmap.org Subject: Re: [OSM-dev] Relation member_roles from Osmosis import Hello Jochen, thanks for your answer, that makes it clear. I have another question about relations. I found a relation, a lake in Germany, (id=1104680, Schweriner See (Außensee)), which has serveral inner relations to ways. Some of these ways form a closed ways, so it's easy to create a polygon from it. But other ways with the relation role inner are not closed, but they form together an island in the lake. Should't those form a relation of themselves before relating them to the lake relation with an inner relation? The ways I am speaking of are 24563810 70191810 70191809 70191807 Luckily those ways form an island but if there would be another island formed by ways without relating them together it is quite difficult to recreate them properly. Is this situation an exception or is this a common situation? Frank Am 27.10.2010 11:01, schrieb Jochen Topf: On Wed, Oct 27, 2010 at 10:39:38AM +0200, Frank Broniewski wrote: During my examinations from an OSM import (osmosis pbf to postgis) I found some strange looking entries in the relation_members table. My goal is to make (GIS) polygons from the linestrings table and therefore I examined the relations a little closer. Doing a select distinct relation_id, member_role from relation_members I find these entries in the result, which I suspect to be wrong relation_id, member_role 22852;forward_stop_0 22852;forward_stop_11 22852;forward_stop_19 22852;forward_stop_9 22852;stop_1 22852;stop_10 22852;stop_12 22852;stop_13 22852;stop_14 300710;backward_stop_%n 207675;forward_stop_%n I think that numbering the member_role is not the intended way ;-) Thats a left-over from the time when relation members were not ordered. Jochen ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Super-relations or not
On Fri, Oct 29, 2010 at 2:45 AM, Peter Budny pet...@gatech.edu wrote: That doesn't work; there are cases where it's ambiguous. If you look at [1], US-278 runs along North Avenue (bottom) and Ponce de Leon Avenue (top), connected by Monroe Drive (left) and Piedmont Avenue (right). The problem is that North Ave and Ponce de Leon are both oneway=no, while Monroe and Piedmont are oneway=yes. So unless you run a routing algorithm over the relation, you can't figure out just from the oneway tags that US-278 westbound doesn't include North Avenue (which you would otherwise assume from it being oneway=no). Someone, somewhere, has messed this up good an proper. I can't find the origins of this discussion to figure out where it's arisen from though. The situation you describe is easily dealt with using Route Relation roles forward and backward as per cycle routes, or bus routes, or every other route relation. See for example http://www.openstreetmap.org/?lat=51.8lon=0.89395zoom=17layers=00B0FTF It's clearly documented here: http://wiki.openstreetmap.org/wiki/Relation:route#Members and rendered on multiple maps. However, I see from elsewhere that people are making route relations in the US and filling the memberships with west and south and suchlike and then finding this causes problems. My advice is to stick to the route relation member roles that work for every other type of route, and if people ray want to have separate routes for I5 East and I5 West then feel free (something that hasn't seemed necessary elsewhere) - but don't put the words east or west in the ref, add an additional tag to the relation for overall direction or something. But please, stick with the forward/backward stuff for route relations roles, it works well. Cheers, Andy ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Relation member_roles from Osmosis import
2010/10/29 Jochen Topf joc...@remote.org: Common. There are many, many broken multipolygon relations. See http://tools.geofabrik.de/osmi/debug.html?view=multipolygonlon=13.04883lat=44.58577zoom=5 There is also a feature touching inner rings which is not an error according to the OSM data scheme (would be according to ogc), but the inspector isn't too verbal about this (it might look like an error if you are not into details). I don't know if this feature is useful (otherwise could be removed), but adding a comment to the mouse-over-description that this is not an error would help IMHO. Cheers, Martin ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Mod_tile - apache 404 - no tiles please help
Hi everyone, i'm setting up a local OSM server on a Debian Lenny 32bit for 3 days, and now i need some help with mod_tile ;) I've installed the postgresql database, postgis, osm2pgsql and mapnik tools correctly (i think :) generate_image.py works well, i can generate static png without problems ! Now i'm trying to set up Mod_tile for rendering and thats a curse for me ! (i'm not a linux professional). i get mod_tile from SVN ; This is how i've setup mod_tile and apache (long list but complete) - MOD TILE Makefile top_dir:=$(shell /usr/bin/apxs2 -q exp_installbuilddir) APXS = apxs2 - render_config.h #define HASH_PATH var/lib/mod_tile #define TILE_PATH /var/www/osm_tiles2 #define RENDERD_CONFIG /etc/renderd.conf #define MAPNIK_PLUGINS /usr/local/lib/mapnik/input #define FONT_DIR /usr/share/fonts/truetype/ttf-dejavu/ #define FONT_RECURSE 1 - renderd.conf (the one in mod_tile folder) [renderd] socketname=/var/run/renderd/renderd.sock num_threads=2 tile_dir=/var/lib/mod_tile ; DOES NOT WORK YET stats_file=/var/run/renderd/renderd.stats [mapnik] plugins_dir=/usr/local/lib/mapnik/input font_dir=/usr/local/lib/mapnik/fonts font_dir_recurse=1 [default] URI=/osm_tiles2/ XML=/root/travaux/osm-mapnik/osm.xml HOST=geolocalisation.renater.fr ;HTCPHOST=proxy.openstreetmap.org --- i've done make, make install the /etc/renderd.conf look like the one above --- APACHE : in /etc/apache2/mods_available i have a file mod_tile.load with this line : LoadModule tile_module /usr/lib/apache2/modules/mod_tile.so and i've loaded it : a2enmod mod_tile in /etc/apache2:site_available i have a site 'osm' with this lines: DocumentRoot /var/www AddTileConfig /osm_tiles2/ default LoadTileConfigFile /etc/renderd.conf ModTileTileDir /var/lib/mod_tile ModTileRenderdSocketName /var/run/renderd/renderd.sock the module is loaded successfully with apache (apache2ctl -t -D DUMP_MODULES) the socket file /var/run/renderd/renderd.sock exist. --- RENDER DEAMON when i launch the render deamon : ./renderd -f renderd[5948]: Rendering daemon started renderd[5948]: Parsing section renderd renderd[5948]: Parsing render section 0 renderd[5948]: Parsing section mapnik renderd[5948]: Parsing section default renderd[5948]: config renderd: unix socketname=/var/run/renderd/renderd.sock renderd[5948]: config renderd: num_threads=2 renderd[5948]: config renderd: num_slaves=0 renderd[5948]: config renderd: tile_dir=/var/lib/mod_tile/ renderd[5948]: config renderd: stats_file=(null) renderd[5948]: config mapnik: plugins_dir=/usr/local/lib/mapnik/input renderd[5948]: config mapnik: font_dir=/usr/share/fonts/truetype/ttf-dejavu/ renderd[5948]: config mapnik: font_dir_recurse=1 renderd[5948]: config renderd(0): Active renderd[5948]: config renderd(0): unix socketname=/var/run/renderd/renderd.sock renderd[5948]: config renderd(0): num_threads=2 renderd[5948]: config renderd(0): tile_dir=/var/lib/mod_tile/ renderd[5948]: config renderd(0): stats_file=(null) renderd[5948]: config map 0: name(default) file(/root/travaux/osm/osm-mapnik/osm.xml) uri(/osm_tiles2/) htcp() host(geolocalisation.renater.fr) renderd[5948]: Initialising unix server socket on /var/run/renderd/renderd.sock renderd[5948]: Created server socket 4 renderd[5948]: DEBUG: Loading font: /usr/share/fonts/truetype/ttf-dejavu//DejaVuSansCondensed-Oblique.ttf renderd[5948]: DEBUG: Loading font: /usr/share/fonts/truetype/ttf-dejavu//DejaVuSans-Bold.ttf renderd[5948]: DEBUG: Loading font: /usr/share/fonts/truetype/ttf-dejavu//DejaVuSansMono.ttf renderd[5948]: DEBUG: Loading font: /usr/share/fonts/truetype/ttf-dejavu//DejaVuSerif.ttf renderd[5948]: DEBUG: Loading font: /usr/share/fonts/truetype/ttf-dejavu//DejaVuSerif-BoldItalic.ttf renderd[5948]: DEBUG: Loading font: /usr/share/fonts/truetype/ttf-dejavu//DejaVuSerifCondensed.ttf renderd[5948]: DEBUG: Loading font: /usr/share/fonts/truetype/ttf-dejavu//DejaVuSansCondensed-BoldOblique.ttf renderd[5948]: DEBUG: Loading font: /usr/share/fonts/truetype/ttf-dejavu//DejaVuSansMono-BoldOblique.ttf renderd[5948]: DEBUG: Loading font: /usr/share/fonts/truetype/ttf-dejavu//DejaVuSansCondensed.ttf renderd[5948]: DEBUG: Loading font: /usr/share/fonts/truetype/ttf-dejavu//DejaVuSans-ExtraLight.ttf renderd[5948]: DEBUG: Loading font: /usr/share/fonts/truetype/ttf-dejavu//DejaVuSans-Oblique.ttf renderd[5948]: DEBUG: Loading font: /usr/share/fonts/truetype/ttf-dejavu//DejaVuSansMono-Oblique.ttf renderd[5948]: DEBUG: Loading font: /usr/share/fonts/truetype/ttf-dejavu//DejaVuSerif-Italic.ttf renderd[5948]: DEBUG: Loading font: /usr/share/fonts/truetype/ttf-dejavu//DejaVuSans-BoldOblique.ttf renderd[5948]: DEBUG: Loading font: /usr/share/fonts/truetype/ttf-dejavu//DejaVuSerif-Bold.ttf renderd[5948]: DEBUG: Loading font: /usr/share/fonts/truetype/ttf-dejavu//DejaVuSansCondensed-Bold.ttf renderd[5948]: DEBUG:
Re: [OSM-dev] Unknown xml element changeset
Hi, On 10/29/10 15:08, Dmytro Korochkin wrote: I'm trying to create the latest planet.osm file with osmosis 0.32.1 , but getting a lot such warnings: [...] Do you know if it is critical? No, you can ignore the messages. If you upgrade to a more recent Osmosis version they will go away. Bye Frederik ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Unknown xml element changeset
Thanks Frederik On Fri, Oct 29, 2010 at 4:50 PM, Frederik Ramm frede...@remote.org wrote: Hi, On 10/29/10 15:08, Dmytro Korochkin wrote: I'm trying to create the latest planet.osm file with osmosis 0.32.1 , but getting a lot such warnings: [...] Do you know if it is critical? No, you can ignore the messages. If you upgrade to a more recent Osmosis version they will go away. Bye Frederik ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev -- Mitya Follow me on Twitter http://twitter.com/mityacor ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Super-relations or not
Andy Allan gravityst...@gmail.com writes: On Fri, Oct 29, 2010 at 2:45 AM, Peter Budny pet...@gatech.edu wrote: That doesn't work; there are cases where it's ambiguous. If you look at [1], US-278 runs along North Avenue (bottom) and Ponce de Leon Avenue (top), connected by Monroe Drive (left) and Piedmont Avenue (right). The problem is that North Ave and Ponce de Leon are both oneway=no, while Monroe and Piedmont are oneway=yes. So unless you run a routing algorithm over the relation, you can't figure out just from the oneway tags that US-278 westbound doesn't include North Avenue (which you would otherwise assume from it being oneway=no). Someone, somewhere, has messed this up good an proper. I can't find the origins of this discussion to figure out where it's arisen from though. The situation you describe is easily dealt with using Route Relation roles forward and backward as per cycle routes, or bus routes, or every other route relation. See for example http://www.openstreetmap.org/?lat=51.8lon=0.89395zoom=17layers=00B0FTF It's clearly documented here: http://wiki.openstreetmap.org/wiki/Relation:route#Members and rendered on multiple maps. However, I see from elsewhere that people are making route relations in the US and filling the memberships with west and south and suchlike and then finding this causes problems. My advice is to stick to the route relation member roles that work for every other type of route, and if people ray want to have separate routes for I5 East and I5 West then feel free (something that hasn't seemed necessary elsewhere) - but don't put the words east or west in the ref, add an additional tag to the relation for overall direction or something. But please, stick with the forward/backward stuff for route relations roles, it works well. Okay, let's presume for a minute that blank/forward/backward is the correct method. I'll grant that it does have its advantages, such as for the scenario I described. However, when I look at http://ra.osmsurround.org/analyze.jsp?relationId=78041 (in Belarus) or http://ra.osmsurround.org/analyze.jsp?relationId=93920 (in Canada), the display is meaningless. It hasn't bothered to connect the forward/backward ways to the ways with no role, so it's totally unclear what's going on. If you want this to be the standard way of tagging things, then we NEED to get the tools up to spec. I also noticed that Potlatch doesn't change the role from forward to backward when you reverse a way. (JOSM does the right thing, though.) My argument for super-relations is that they pretty much work NOW. You don't have to look at the roles... one relation contains one direction, end-to-end. P.S. I don't know why people haven't complained about this more. Maybe because most of the route relations are on motorways, which are almost universally dual-carriageway. In the US where lots of minor roads are signed as routes, and routes are sometimes discontiguous, I think the issues [will] stand out a little more. P.P.S. Why do I see so many route relations where a way has been added more than once, sometimes up to 5 times, with the same role? What is that supposed to mean? -- Peter Budny \ Georgia Tech \ CS PhD student \ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] User-friendly interface to OSM POIs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 My OSM-based navigation app is finally maturing to the point where users can add POIs, and I hope to add search soon. Only, in diving into the OSM recommendations on tagging map features, I'm having a hard time wrapping my mind around how users might search for points, or easily contribute them to the OSM database. Say, for instance, a user wishes to search for nearby restaurants. How might one design a search interface that queries an OSM database for this information? At the moment, I'm using a freeform text box that sends a query to multiple back-end agents. Current candidates are Yahoo's geocoding API for addresses and, if I'm allowed to do so by its TOS, Mapquest's API for nearby POIs. But say someone types in restaurants. I'm not sure how to transition from that to a meaningful OSM query. Singularize it, obviously, but the features page would seem to indicate that searching for amenity=restaurant isn't enough. Leaving aside the issue of whether or not fast food is in fact food, I'd also have to search for that, plus food_court and maybe a few others I've missed. And that's just for the case of wanting to find a restaurant. I'm sure there are more that I've missed, where a common category would translate into several combinations of tag queries. So I'm wondering how people have implemented this, if anyone in fact has? Right now it seems like I'd have to map common words like restaurant to combinations of tag queries. Has anyone created such a list of category keywords and mappings? Many can be intelligently handled I'm sure, but there are likely quite a few that would need to search multiple tag combinations to provide the most meaningful results. Or maybe this freeform text field isn't the best approach and instead I should just have a dropdown list of categories? The problem is similar for adding points. I want to give users the ability to add their own tags, and to see all the tags assigned to a given point, but it'd be great if I could just click a button or something and have my app request information specific to a given tag type. Has anyone had success with a UI for doing this, and if so, again has some sort of tag mapping been created (I.e. the amenity=restaurant tag is related to cuisine, so allow that to be entered if desired.) Thanks. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzK+UoACgkQIaMjFWMehWJEDQCcD0oHEEj5BbJR1BXMT35AKDEq vfMAnjpqWIrGKZLQyM9tvQxAze8wGzIu =tK1u -END PGP SIGNATURE- ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Mod_tile - apache 404 - no tiles please help
On 29 October 2010 23:26, NicoG garn...@renater.fr wrote: did i forget something ? thx you for your help I couldn't see your mod_tile config, but you need to have a look at mod_tile.conf examples that come with mod_tile... ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] User-friendly interface to OSM POIs
You won't want to query the OSM API directly, you could use something like Nominatim or CloudMade's API which is designed for these types of queries. For adding the data to OSM, you may want to Look at the CloudMade POI Collector on iPhone, or Potlatch 2, which both abstract the tags away into nice categories etc. Shaun On 29 Oct 2010, at 17:41, Nolan Darilek wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 My OSM-based navigation app is finally maturing to the point where users can add POIs, and I hope to add search soon. Only, in diving into the OSM recommendations on tagging map features, I'm having a hard time wrapping my mind around how users might search for points, or easily contribute them to the OSM database. Say, for instance, a user wishes to search for nearby restaurants. How might one design a search interface that queries an OSM database for this information? At the moment, I'm using a freeform text box that sends a query to multiple back-end agents. Current candidates are Yahoo's geocoding API for addresses and, if I'm allowed to do so by its TOS, Mapquest's API for nearby POIs. But say someone types in restaurants. I'm not sure how to transition from that to a meaningful OSM query. Singularize it, obviously, but the features page would seem to indicate that searching for amenity=restaurant isn't enough. Leaving aside the issue of whether or not fast food is in fact food, I'd also have to search for that, plus food_court and maybe a few others I've missed. And that's just for the case of wanting to find a restaurant. I'm sure there are more that I've missed, where a common category would translate into several combinations of tag queries. So I'm wondering how people have implemented this, if anyone in fact has? Right now it seems like I'd have to map common words like restaurant to combinations of tag queries. Has anyone created such a list of category keywords and mappings? Many can be intelligently handled I'm sure, but there are likely quite a few that would need to search multiple tag combinations to provide the most meaningful results. Or maybe this freeform text field isn't the best approach and instead I should just have a dropdown list of categories? The problem is similar for adding points. I want to give users the ability to add their own tags, and to see all the tags assigned to a given point, but it'd be great if I could just click a button or something and have my app request information specific to a given tag type. Has anyone had success with a UI for doing this, and if so, again has some sort of tag mapping been created (I.e. the amenity=restaurant tag is related to cuisine, so allow that to be entered if desired.) Thanks. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzK+UoACgkQIaMjFWMehWJEDQCcD0oHEEj5BbJR1BXMT35AKDEq vfMAnjpqWIrGKZLQyM9tvQxAze8wGzIu =tK1u -END PGP SIGNATURE- ___ 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] User-friendly interface to OSM POIs
But say someone types in restaurants. I'm not sure how to transition from that to a meaningful OSM query. So I'm wondering how people have implemented this, if anyone in fact has? In the case of a Smartphone for POI search, a list of categories is the best method rather than requiring typing. For OSM data, you would query using Xapi http://wiki.openstreetmap.org/wiki/Xapi . Right now it seems like I'd have to map common words like restaurant to combinations of tag queries. Has anyone created such a list of category keywords and mappings? Many can be intelligently handled I'm sure, but there are likely quite a few that would need to search multiple tag combinations to provide the most meaningful results. I haven't seen anyone do this properly (in my opinion). For Gastronomy for example, I'd like to see combined results of amenity=restaurant amenity=fast_food amenity=food_court amenity=ice_cream amenity=café amenity=pub amenity=bar So, you might either get all amenity= with Xapi and filter internally, or have a multiple-amenity query. You'll need to query for both nodes and ways.Some people may prefer to directly query directly for one of the above categories. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
