[OSM-dev] sorry it's a test
vandalism ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] sorry it's second and the last test
arf afaf fsfs ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
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 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Export tab
I often find myself wanting an OSM map url to a map with a marker to send in an email. I can do this with the Export Embeddable HTML, add marker, and then editing the HTML to extract the link (which also means changing the amps), or it can be done manually by tediously copying a lat/lon and typing them in as mlat and mlon in an addition to the link... Any chance this could be done as a minor change to the site, added as an option directly? Either as: - another option on the Export tab, like the Embeddable HTML but with just the link to copy and paste, or - a general add marker option somewhere with the marker reflected in the permalink and short link or something similar. I'd do it myself, but I don't know Rails at all well. David ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Relation member_roles from Osmosis import
Jochen Topf joc...@remote.org writes: On Wed, Oct 27, 2010 at 10:39:38AM +0200, Frank Broniewski wrote: Thats a left-over from the time when relation members were not ordered. Someone in another thread just told me relation members /aren't/ ordered, and that the ordering that, say, JOSM displays is just as a tool to aid the user... not for any semantic purpose. Which is it? -- Peter Budny \ Georgia Tech \ CS PhD student \ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Relation member_roles from Osmosis import
Frank Broniewski b...@metrico.lu writes: 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? I don't know if it's common, but it is documented on the wiki as a valid way of using multipolygons. It may not be the best way, though. If the islands have any tags associated with them (like name=*) it would probably be better to split them off into their own relation. -- Peter Budny \ Georgia Tech \ CS PhD student \ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Relation member_roles from Osmosis import
On Thu, Oct 28, 2010 at 9:14 AM, Peter Budny pet...@gatech.edu wrote: Jochen Topf joc...@remote.org writes: On Wed, Oct 27, 2010 at 10:39:38AM +0200, Frank Broniewski wrote: Thats a left-over from the time when relation members were not ordered. Someone in another thread just told me relation members /aren't/ ordered, and that the ordering that, say, JOSM displays is just as a tool to aid the user... not for any semantic purpose. Which is it? http://wiki.openstreetmap.org/wiki/Elements#Relation says The ordering of elements within a relation is persistent. The members are returned in the order specified at upload. Duplicate elements will retain their specified order. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Export tab
The easiest way is to get the shortlink URL and append ?m to the end. On Thu, Oct 28, 2010 at 9:44 PM, David Earl da...@frankieandshadow.com wrote: I often find myself wanting an OSM map url to a map with a marker to send in an email. I can do this with the Export Embeddable HTML, add marker, and then editing the HTML to extract the link (which also means changing the amps), or it can be done manually by tediously copying a lat/lon and typing them in as mlat and mlon in an addition to the link... Any chance this could be done as a minor change to the site, added as an option directly? Either as: - another option on the Export tab, like the Embeddable HTML but with just the link to copy and paste, or - a general add marker option somewhere with the marker reflected in the permalink and short link or something similar. I'd do it myself, but I don't know Rails at all well. David ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev -- http://vaes9.codedgraphic.com ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Export tab
Eugene Alvin Villar wrote: The easiest way is to get the shortlink URL and append ?m to the end. It's the fastest solution, and you don't have to use third-party sites for it. There are some other options, too: http://help.openstreetmap.org/questions/25/how-do-i-add-a-marker-to-a-map Nevertheless, it would be nice to be able to do this on openstreetmap.org's /graphical/ user interface. I don't consider any solution based on URL editing easy (or user friendly). Tobias Knerr ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Export tab
On Thu, 28 Oct 2010 22:24:56 +0800, Eugene Alvin Villar sea...@gmail.com wrote: The easiest way is to get the shortlink URL and append ?m to the end. And the next easiest way is to get the permalink and add m in front of lat and lon. But, the challange is to get lat and lon right. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Super-relations or not (was: Relation member_roles from Osmosis import)
(sorry for the crossposting, but this really applies globally, as well as for recent discussions on the talk-us list) Ian Dees ian.d...@gmail.com writes: On Thu, Oct 28, 2010 at 9:14 AM, Peter Budny pet...@gatech.edu wrote: Jochen Topf joc...@remote.org writes: On Wed, Oct 27, 2010 at 10:39:38AM +0200, Frank Broniewski wrote: Thats a left-over from the time when relation members were not ordered. Someone in another thread just told me relation members /aren't/ ordered, and that the ordering that, say, JOSM displays is just as a tool to aid the user... not for any semantic purpose. Which is it? http://wiki.openstreetmap.org/wiki/Elements#Relation says The ordering of elements within a relation is persistent. The members are returned in the order specified at upload. Duplicate elements will retain their specified order. Aha. Now that's interesting. To me, this says we really ought to be using super-relations for route relations, rather than a single relation with roles tagged, for 2 reasons: 1) The common way, up to now, for storing routes that alternate between single- and dual-carriageway has been to leave the single-carriageway parts without a role, or with the role north/south. This makes the order of the members of the relation meaningless, since you can't traverse the ways end-to-end in the specified order. This could be solved by adding the single-carriageway sections twice (once with north and once with south), but at that point, why not take the extra 5 seconds and do super-relations? 2) If the direction of a road (e.g. north/south) is indicated by roles, how do you refer to it elsewhere? For example, if you have a destination sign that says it goes to I-75 Northbound, and all of I-75 is in one relation with roles for north and south, how do you refer to just one direction of the road? You can't refer to the whole relation (because that doesn't reflect what the sign says), and there's no clear way to refer to a role of a relation. With super-relations, this isn't a problem... there would be a subrelation that unambiguously refers to just the northbound or southbound part of the road. I really think that super-relations for routes are the way to go... all the methods are really equivalent, but super-relations are easier to deal with programmatically, preserve a little more information, and are not really any more difficult for users/mappers. If anyone has a compelling argument against super-relations, or for single relations, I'd like to hear it. Supporting both seems really pointless, and I think it's about time we picked one or the other so we can develop proper support for route relations and tools to support them moving forward. -- Peter Budny \ Georgia Tech \ CS PhD student \ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Export tab
On 28/10/2010 15:24, Eugene Alvin Villar wrote: The easiest way is to get the shortlink URL and append ?m to the end. That only marks the centre of the map, which requires some careful judgement, rather than being able to point at the desired feature. David ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Export tab
On Thu, October 28, 2010 3:49 pm, Matthias Julius wrote: On Thu, 28 Oct 2010 22:24:56 +0800, Eugene Alvin Villar sea...@gmail.com wrote: The easiest way is to get the shortlink URL and append ?m to the end. And the next easiest way is to get the permalink and add m in front of lat and lon. But, the challange is to get lat and lon right. Easy: double click in the centre of the map (and then zoom out if required) and the map will be centred on the point that you have double clicked. Shaun ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] i18n update issue
Claudius wrote: There seems to be an issue with the i18n update from launchpad. Many strings that were translated into German in Launchpad have not made it through to the client. For example the Vacuum cleaner preset entry is in launchpad since october 17th: https://translations.launchpad.net/josm/trunk/+pots/josm/de/+translate?batch=10show=allsearch=vacuum+cleaner ...and bastiK did a i18n update in r3639 on 24th ( http://josm.openstreetmap.de/changeset/3639/josm ), but still in 3640's UI those strings show untranslated. Same applies for Greengrocer and several other strings. Claudius Thanks for reporting the issue. I cannot say what went wrong, but after another update [3644], the translations are in. Sebastian ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] full history dump 2010-10-22
On Mon, Oct 25, 2010 at 8:20 PM, Marco Lechner - FOSSGIS e.V. marco.lech...@fossgis.de wrote: Hi Matt, thank you. Is it just a more recent one or are there any changes in the schema? it's just a more recent one for convenience. it should be identical to the intervening replication diffs applied to the previous full history planet. cheers, matt Marco Am 25.10.2010 21:03, schrieb Matt Amos: there's a new full history file available: http://planet.openstreetmap.org/full-experimental/full-planet-101022.osm.bz2 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 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Relation member_roles from Osmosis import
2010/10/28 Peter Budny pet...@gatech.edu: Jochen Topf joc...@remote.org writes: On Wed, Oct 27, 2010 at 10:39:38AM +0200, Frank Broniewski wrote: Thats a left-over from the time when relation members were not ordered. Someone in another thread just told me relation members /aren't/ ordered, and that the ordering that, say, JOSM displays is just as a tool to aid the user... not for any semantic purpose. Which is it? In the past it was like this, now relations are ordered and maintain the order that is e.g. in JOSM displayed / arranged. This is needed/helpful for routes but multipolygons don't require a particular order AFAIK. cheers, Martin ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Super-relations or not
Hi, Peter Budny wrote: 1) The common way, up to now, for storing routes that alternate between single- and dual-carriageway has been to leave the single-carriageway parts without a role, or with the role north/south. This makes the order of the members of the relation meaningless, since you can't traverse the ways end-to-end in the specified order. There is no requirement for the order to have meaning; it is just a tool the server offers you, and you can use it or not. The way I view route relations, it is less about traversal and more about simply stating that a certain way belongs to a certain route. The route relation doesn't lose its usefulness if a little bit in the middle is missing. I would simply group all bits together in the route relation, including the dual carriageway pieces, and not worry about roles etc. - this can all be deducted from the oneway tags. This could be solved by adding the single-carriageway sections twice (once with north and once with south) Please no. 2) If the direction of a road (e.g. north/south) is indicated by roles, I recommend not to do that. If anyone has a compelling argument against super-relations, or for single relations, I'd like to hear it. Supporting both seems really pointless No, supporting them both is quite probably the best way forward. You can start with doing a simple relation, and when you find that there's something more complex to it you can still use a super-relation. I always preach that you should write your code such that wherever you expect a way, you also accept a relation that groups a number of ways. If that were done throughout, then a super-relation would just be a normal relation with one or two sub-relations thrown in as required. No need to go up the tree and demand that super-relations exclusively contain relations etc. 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
[OSM-dev] i18n : yml2po ?
Hello, The current i18n work on the website is based on Ruby on rail and yml files. Does anybody knows if these yml exists somewhere in GNU gettext .po format? Or an easy way to use directly these yml files in Python without gettext() ? I'm working on a python tool to extract a mapkey from the xml stylesheet, and that would be great to add i18n features. And just translate the yaml work available to another set of .po files rather splits that work. Yves ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] i18n : yml2po ?
On Thursday 28 October 2010 21:54:37 yvecai wrote: The current i18n work on the website is based on Ruby on rail and yml files. Does anybody knows if these yml exists somewhere in GNU gettext .po format? Or an easy way to use directly these yml files in Python without gettext()? You could use PyYAML http://pyyaml.org/ Mitja ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Super-relations or not
Frederik Ramm frede...@remote.org writes: Hi, Peter Budny wrote: 1) The common way, up to now, for storing routes that alternate between single- and dual-carriageway has been to leave the single-carriageway parts without a role, or with the role north/south. This makes the order of the members of the relation meaningless, since you can't traverse the ways end-to-end in the specified order. There is no requirement for the order to have meaning; it is just a tool the server offers you, and you can use it or not. The way I view route relations, it is less about traversal and more about simply stating that a certain way belongs to a certain route. The route relation doesn't lose its usefulness if a little bit in the middle is missing. I would simply group all bits together in the route relation, including the dual carriageway pieces, and not worry about roles etc. - this can all be deducted from the oneway tags. 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). On top of that, TIGER data in the US didn't have oneway information, so lots of oneway roads here are still not tagged as such. (We can create the route relations because there's metadata from the import, and Wikipedia pages, that tell us where the road goes... but knowing if a road is oneway often requires local knowledge.) Super-relations are always unambiguous, and are easier to process. [1] http://maps.google.com/?ie=UTF8ll=33.771926,-84.382652spn=0.001561,0.002645z=19 This could be solved by adding the single-carriageway sections twice (once with north and once with south) Please no. Agreed on this point. If anyone has a compelling argument against super-relations, or for single relations, I'd like to hear it. Supporting both seems really pointless No, supporting them both is quite probably the best way forward. You can start with doing a simple relation, and when you find that there's something more complex to it you can still use a super-relation. We don't support *either* very well right now, and you want to support *both*? -- Peter Budny \ Georgia Tech \ CS PhD student \ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[josm-dev] i18n update issue
There seems to be an issue with the i18n update from launchpad. Many strings that were translated into German in Launchpad have not made it through to the client. For example the Vacuum cleaner preset entry is in launchpad since october 17th: https://translations.launchpad.net/josm/trunk/+pots/josm/de/+translate?batch=10show=allsearch=vacuum+cleaner ...and bastiK did a i18n update in r3639 on 24th ( http://josm.openstreetmap.de/changeset/3639/josm ), but still in 3640's UI those strings show untranslated. Same applies for Greengrocer and several other strings. Claudius ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] i18n update issue
Hi, On 10/28/10 11:01, Claudius wrote: There seems to be an issue with the i18n update from launchpad. Many strings that were translated into German in Launchpad have not made it through to the client. For example the Vacuum cleaner preset entry is in launchpad since october 17th: I must have been busy with something else when OSM made the jump from mapping the world outside to managing household appliances. Bye Frederik ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[josm-dev] Meters to Pixels
Hi! Another question.. There is a method that converts meters in pixels? Have a nice day Irene ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Meters to Pixels
2010/10/28 Irene Pucci ipu...@navionics.it: Hi! Another question.. There is a method that converts meters in pixels? this depends on the resolution and aspect ratio of the pixels. If you print at 300dpi and pixels/dots are 1:1 (height:width) you can easily calculate that 1 pixel measures 1/300inch = 0,0033 inches (rounded). So one pixel is around 0,84667 metres at 300 dpi. Screen resolutions vary. cheers, Martin ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Meters to Pixels
Thank you so much! But, for example, if I have the value (in meters) of the distance between two nodes (n.getCoor().distance(n1.getCoor())), can I convert this value in pixels? Cheers, Irene -Original Message- From: dieterdre...@gmail.com [mailto:dieterdre...@gmail.com] Sent: giovedì 28 ottobre 2010 12.11 To: Irene Pucci Cc: josm-dev@openstreetmap.org Subject: Re: [josm-dev] Meters to Pixels 2010/10/28 Irene Pucci ipu...@navionics.it: Hi! Another question.. There is a method that converts meters in pixels? this depends on the resolution and aspect ratio of the pixels. If you print at 300dpi and pixels/dots are 1:1 (height:width) you can easily calculate that 1 pixel measures 1/300inch = 0,0033 inches (rounded). So one pixel is around 0,84667 metres at 300 dpi. Screen resolutions vary. cheers, Martin ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] i18n update issue
On Thu, 28 Oct 2010 11:28:23 +0200, Frederik Ramm frede...@remote.org wrote: Hi, On 10/28/10 11:01, Claudius wrote: There seems to be an issue with the i18n update from launchpad. Many strings that were translated into German in Launchpad have not made it through to the client. For example the Vacuum cleaner preset entry is in launchpad since october 17th: I must have been busy with something else when OSM made the jump from mapping the world outside to managing household appliances. I guess people have started to micro-map their apartments now. Or is it about stuf you might find at fuel stations? Matthias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] i18n update issue
through to the client. For example the Vacuum cleaner preset entry is in launchpad since october 17th: I must have been busy with something else when OSM made the jump from mapping the world outside to managing household appliances. G I think it refers to the Vacuum Cleaner shop like http://www.mid-michiganvacuum.com/graphics/ShopOutsideNewLook107.jpg . Some vacuum cleaner shops are even bigger than that. But it must suck to work there! ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] i18n update issue
G I think it refers to the Vacuum Cleaner shop like http://www.mid-michiganvacuum.com/graphics/ShopOutsideNewLook107.jpg . Funny enough, I actually tagged one of those here in Germany: http://www.openstreetmap.org/browse/node/671401939/history And yes, I found this on the osm wiki. I wouldn't dare to come up with this myself. Stefan ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Meters to Pixels
Am Do, 28.10.2010, 12:04 schrieb Irene Pucci: There is a method that converts meters in pixels? Since digital screens have different pixel sizes, there are two main specifications in GIS world: 1. based on 96 ppi (about 0.026458333 millimeters) 2. based on 0.28 millimeters (about 90.71423 ppi) 3. based on your real monitor 1. has historic reasons 2. is an OGC-standard: http://www.opengeospatial.org/standards/sld 3. you can check this on http://www.infobyip.com/detectmonitordpi.php 1. Is used on ArcGIS (I only know for v9.x) 2. Is used on Mapnik. Best regards, Tobias ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Meters to Pixels
At 2010-10-28 06:32, Tobias Wendorff wrote: Am Do, 28.10.2010, 12:04 schrieb Irene Pucci: There is a method that converts meters in pixels? In the Windows environment anyway, there are API calls that are used to deal with screen, print, etc. metrics. The easiest way to find out, though, is to experiment. For me, in JOSM, the zoom level in meters corresponds to 100 pixels. I can confirm this by drawing a segment the length of the scale bar and confirming its size as 100 pels by capturing the image and examining it with a graphic editor. You can see in the measurement dialog* that the way is equal in length to the current scale. You can also calculate the distance between the endpoints using any of the standard geoscience tools and see that it concurs within reason* for short distances. There are issues of arc length vs. projected length vs. whatever for longer distances. *Note: Both the measurement dialog and the status line in JOSM are slightly wrong (though different from each other), as reported in http://josm.openstreetmap.de/ticket/4849. Also note in that report that the area is very wrong away from the equator. -- Alan Mintz alan_mintz+...@earthlink.net ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
