Re: [Talk-hr] Promotivni OSM letak
Ovo je vise plakat. Letak mora imati vise informacija. srijeda, 26. veljače 2014. korisnik valent.turko...@gmail.com valent.turko...@gmail.com napisao je: Nope, za manji plakat ide i manje informacija, ako staviš hrpe teksta budi siguran da će sve završiti u košu. Informacije se daju usmeno ili na webu. Letak je tu samo da ih privuče. On 26 Feb 2014 23:20, hbogner hbog...@gmail.com javascript:; wrote: On 02/26/2014 11:16 PM, valent.turko...@gmail.com javascript:; wrote: Evo png i Inkscape verzije: https://www.dropbox.com/s/b5vv06xmveq4uyc/OSM%20plakat.png https://www.dropbox.com/s/7e1sg0ur3kuldjk/OSM%20plakat.svg Kao što naziv kaže ovo je super za neki veći plakat :D Za A6 letak bi ipak stavio nešto više informacija. ___ Talk-hr mailing list Talk-hr@openstreetmap.org javascript:; https://lists.openstreetmap.org/listinfo/talk-hr ___ Talk-hr mailing list Talk-hr@openstreetmap.org javascript:; https://lists.openstreetmap.org/listinfo/talk-hr -- Svega što vrijedi Bog je stvorio malo, kako zlata tako i Hrvata. ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Promotivni OSM letak
Ovo je samo prijedlog prednje stranice, dakle ovo nije cijeli letak, na drugoj stranici (koja je objavljena na FB) se nalaze dodatne informacije. Imam dosta iskustva rada sa ljudima, letcima i promocijom pa eto iskoristiti to moje iskustvo :) 2014-02-27 9:15 GMT+01:00 SilverSpace mirozag...@ubuntu-hr.org: Ovo je vise plakat. Letak mora imati vise informacija. srijeda, 26. veljače 2014. korisnik valent.turko...@gmail.com valent.turko...@gmail.com napisao je: Nope, za manji plakat ide i manje informacija, ako staviš hrpe teksta budi siguran da će sve završiti u košu. Informacije se daju usmeno ili na webu. Letak je tu samo da ih privuče. On 26 Feb 2014 23:20, hbogner hbog...@gmail.com wrote: On 02/26/2014 11:16 PM, valent.turko...@gmail.com wrote: Evo png i Inkscape verzije: https://www.dropbox.com/s/b5vv06xmveq4uyc/OSM%20plakat.png https://www.dropbox.com/s/7e1sg0ur3kuldjk/OSM%20plakat.svg Kao što naziv kaže ovo je super za neki veći plakat :D Za A6 letak bi ipak stavio nešto više informacija. ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr -- Svega što vrijedi Bog je stvorio malo, kako zlata tako i Hrvata. -- follow me - www.twitter.com/valentt http://kernelreloaded.blog385.com linux, anime, spirituality, wireless, scuba, linuxmce smart home, zwave ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turko...@hotmail.com ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Promotivni OSM letak
Došli smo na 3 prijedloga a samo 2 možemo uzeti za sad: https://dl.dropboxusercontent.com/u/3220458/valent_OSM_plakat.png https://dl.dropboxusercontent.com/u/3220458/vedranv_plakat_OSM_1.png https://dl.dropboxusercontent.com/u/3220458/vedranv_plakat_OSM_2.png Hoćemo Valentov s jedne strane a Vedranov osm-rh.org s druge strane? Hoćemo Valentov s jedne strane a Vedranov osm.org s druge strane? Hoćemo Vedranov osm-rh.org s jedne strane a osm.org s druge strane? Ili da ih žicamo da još nešto izkombiniraju? Sjetite se da oni ovo rade dobrovoljno :D ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Promotivni OSM letak
https://dl.dropboxusercontent.com/u/3220458/2014-02-27-letak.jpg :D ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Promotivni OSM letak
Zakon! On 27 February 2014 13:55, hbogner hbog...@gmail.com wrote: https://dl.dropboxusercontent.com/u/3220458/2014-02-27-letak.jpg :D ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr -- follow me - www.twitter.com/valentt http://kernelreloaded.blog385.com linux, anime, spirituality, wireless, scuba, linuxmce smart home, zwave ICQ: 2125241, Skype: valent.turkovic, MSN: valent.turko...@hotmail.com ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr
Re: [OSM-talk-be] 1 or 2 lanes ?
Hi Gilbert, I'm not sure at all, I just had a quick look at the wiki but maybe this is a solution? http://wiki.openstreetmap.org/wiki/Shoulder Met vriendelijke groeten, Best regards, Ben Abelshausen On Wed, Feb 26, 2014 at 9:40 PM, Gilbert Hersschens gherssch...@gmail.comwrote: I have a highway with separate roads in each direction. Each road has one lane for traffic and one breakdown lane to the right. Normally we tag this as a road with one one-way lane (we only count TRAFFIC lanes, see http://wiki.openstreetmap.org/wiki/Key:lanes). The highway goes through a tunnel. Each road has its own pipe in the tunnel. When entering the tunnel, the breakdown lane is now marked as a spare lane where traffic is not allowed (red X signal above the lane). The idea is to open the spare lane in case of accidents or in case the pipe in the other direction needs to be closed and the normal lane will be used for traffic in the opposite direction. How should this be tagged ? Change from lanes = 1 to lanes = 2 and back to one when we are at the end of the tunnel? Are there additional tags for such a situation ? Examples ? Gilbert ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] 1 or 2 lanes ?
Hi, From the same lane page on the Wiki http://wiki.openstreetmap.org/wiki/Key:lanes: If the lane is also regulary opened with heavy traffic (spitsstrook http://nl.wikipedia.org/wiki/Spitsstrook) then it should be counted (lanes=2), if it is only used for emergencies it is a shoulder and should not be counted (lanes=1). Just my take. Regards, Gerard. Ben Abelshausen wrote: Hi Gilbert, I'm not sure at all, I just had a quick look at the wiki but maybe this is a solution? http://wiki.openstreetmap.org/wiki/Shoulder Met vriendelijke groeten, Best regards, Ben Abelshausen On Wed, Feb 26, 2014 at 9:40 PM, Gilbert Hersschens gherssch...@gmail.com mailto:gherssch...@gmail.com wrote: I have a highway with separate roads in each direction. Each road has one lane for traffic and one breakdown lane to the right. Normally we tag this as a road with one one-way lane (we only count TRAFFIC lanes, see http://wiki.openstreetmap.org/wiki/Key:lanes). The highway goes through a tunnel. Each road has its own pipe in the tunnel. When entering the tunnel, the breakdown lane is now marked as a spare lane where traffic is not allowed (red X signal above the lane). The idea is to open the spare lane in case of accidents or in case the pipe in the other direction needs to be closed and the normal lane will be used for traffic in the opposite direction. How should this be tagged ? Change from lanes = 1 to lanes = 2 and back to one when we are at the end of the tunnel? Are there additional tags for such a situation ? Examples ? Gilbert ___ Talk-be mailing list Talk-be@openstreetmap.org mailto:Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-legal-talk] [Talk-ca] Nouvelle licence de données ouvertes au Québec
Am 27.02.2014 01:03, schrieb Luis Villa: ... Note that this is a substantially different task for 4.0 than for 3.0, because 4.0 (particularly BY-SA) now includes a database copyleft clause. Assessing how the ODBL and CC BY-SA 4.0 database clauses interact will be challenging. OSM/Open Data Commons could simplify the problem by declaring that CC 4.0 is a compatible license under ODBL 4.4(a)(iii), but there would still be some complexities To be clear, this is something that we (as in the OSMF) clearly would NOT want to happen as it would have the effect of removing the contractual nature (see ODbL 1.0 2.1c) of the ODbL in legislations that do not have sui generis database rights. The only thing we are interested in is the case of CC by 4.0 as an input licence (while CC by-SA x.x in principle could work too, using share alike data as an input is a not an option for other reasons). Simon ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] Not attaching polygons to roads
On Wed, Feb 26, 2014 at 2:42 AM, Dave F. dave...@madasafish.com wrote: On 26/02/2014 01:02, Mike Thompson wrote It would be pretty silly to have a municiple boundary splitting the centre of a road so different administrations were responsible for maintaining the left the right. And yet: exactly that is done. Commonly there's a maintenance arrangement, but I could hop on a bicycle and in a few moments take a photo of a street paved in halves for exactly this reason. Even if legal boundary is one edge of the road the customary boundary is likely 'the road', and nobody short of a land surveyor really need care. Roads in OSM are a funny beast since they're drawn with zero dimension, but rendered and processed with width depending on the emphasis of the result. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
And sometimes it matters, and sometimes it doesn't. For boundaries between higher-level administrations with highways responsibility, it matters. District Councils and Civil Parishes (in the UK) for example don't usually have highways responsiblities, so won't matter *in this case* whether the boundary is the centre line or an edge or some random wiggle between two points. A County boundary on the other hand would be significant. Colin On 2014-02-27 09:07, Bryce Nesbitt wrote: On Wed, Feb 26, 2014 at 2:42 AM, Dave F. dave...@madasafish.com wrote: On 26/02/2014 01:02, Mike Thompson wrote It would be pretty silly to have a municiple boundary splitting the centre of a road so different administrations were responsible for maintaining the left the right. And yet: exactly that is done. Commonly there's a maintenance arrangement, but I could hop on a bicycle and in a few moments take a photo of a street paved in halves for exactly this reason. Even if legal boundary is one edge of the road the customary boundary is likely 'the road', and nobody short of a land surveyor really need care. Roads in OSM are a funny beast since they're drawn with zero dimension, but rendered and processed with width depending on the emphasis of the result. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How to Tag Closed Airport
I sometimes add the survey date in my changeset (comment or a specific tag). This has been more for interest of how long i take. On 26 Jan 2014 19:58, Bryce Nesbitt bry...@obviously.com wrote: On Sun, Jan 26, 2014 at 6:04 AM, John F. Eldredge j...@jfeldredge.com wrote: The when last observed disclaimer is unnecessary. Any recorded status is going to be when last observed, unless you are talking about a live broadcast. Not necessarily. A user of Walking Papers http://walking-papers.org/ in particular might record observations made previously. And an intermediate edit might be made that does not involve an observation. In pseudotagging: emergency=aed lastcheck=needs_repair lastcheck:date=2013-12-01 lastcheck:note=Cover ripped off and unit missing. lastcheck:source=December Kenya gps mapping party changeset date=2014-01-01 note=adjusted position of AED to match building outline source=bing changeset date=2013-12-06 note=Added AED found in airport source=survey ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How to Tag Closed Airport
One thing to consider is adding some sort of subsidiary tags, such as suggested, add closed to the name, but leave the main aeroway tagged for a few years. If an airport suddenly disappears from normal map rendering there is a natural assumption by map users that OpenStreetMap is in error. I have no strong views on the correctness of that, but it is pragmatic. http://www.openstreetmap.org/node/86784991 Stockholm-Barkarby flygplats (Nedlagd) Mike On 26/01/2014 07:49, Bryce Nesbitt wrote: I favor disused=yes, perhaps with access=no and a note=. The wiki page http://wiki.openstreetmap.org/wiki/Disused would favor disused:aeroway=aerodrome -Byce Notes 1) Were there an objectnote:en= feature meant for display in map clients, this would be a good addition also. Note 2) While not relevant here, the OSM lifecycle tags are missing a number of steps: broken when last observed is the lifecycle stage I most frequently want to map. There's also under construction but not finished when last observed. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How to Tag Closed Airport
2014-02-27 16:32 GMT+01:00 Michael Collinson m...@ayeltd.biz: One thing to consider is adding some sort of subsidiary tags, such as suggested, add closed to the name, but leave the main aeroway tagged for a few years. If an airport suddenly disappears from normal map rendering there is a natural assumption by map users that OpenStreetMap is in error. I have no strong views on the correctness of that, but it is pragmatic. http://www.openstreetmap.org/node/86784991 Stockholm-Barkarby flygplats (Nedlagd) Mike I don't like this practice. You are adding several incorrect statements (wrong name of the former airport, and the fact that there is no airport) because some people are going to be confused by the fact that an airport has disappeared. So if someone runs a script to see how many airports there are in the US, they are going to get a wrong number. A classical case of mapping for the renderer, because if the renderer rendered disused:aeroway=airport, this wouldn't be an issue. Janko ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
Part of the border of Davidson County in Tennessee, USA runs down the centerline of a road. On February 26, 2014 12:42:00 PM CST, moltonel 3x Combo molto...@gmail.com wrote: On 26/02/2014, Dave F. dave...@madasafish.com wrote: On 26/02/2014 11:16, Maarten Deen wrote: On 2014-02-26 11:42, Dave F. wrote: It would be pretty silly to have a municiple boundary splitting the centre of a road so different administrations were responsible for maintaining the left the right. Like here [1]. The border is in the middle of the road, Actually in the /middle/ of the road? I see no evidence of that. I'm not suggesting Google Maps are definitive, but they show it to one side. I don't have a link to share, but there is such a road in my hometown in France. It caused no end of grief from the residents, because either both municipalities would decide to do no road improvement at all, or they'd work on only half the road. If you thought municipalities and road administrations never do silly things, think again. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk -- John F. Eldredge -- j...@jfeldredge.com Darkness cannot drive out darkness; only light can do that. Hate cannot drive out hate; only love can do that. Dr. Martin Luther King, Jr.___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
On Thu, 2014-02-27 at 10:28 -0600, John F. Eldredge wrote: Part of the border of Davidson County in Tennessee, USA runs down the centerline of a road. The village of Llanymynech straddles the England (Shropshire)/Wales (Powis) border, the border runs up the middle of the main street (A483) http://www.openstreetmap.org/#map=16/52.7811/-3.0902 The bi-lingual Slow/Araf markers painted on the road suggest that Powis look after it. Phil (trigpoint) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] State of the Map US update - schedule is up
Hi all, SOTM US 2014 is shaping up! The schedule is out now -- http://stateofthemap.us/schedule/ and we also have a blog post with some more info over at openstreetmap.us: http://openstreetmap.us/2014/02/stateofthemap-us-schedule/ If you haven't registered yet, this is a great time to do it, and plan your travel. We have a discounted hotel room deal with the Washington Plaza that is pretty nice, but you need to book before *Mar 11*: http://openstreetmap.us/2014/02/hotel-discount-dc/. We also have a wiki page on the osm.org wiki with sections for ride / room sharing: https://wiki.openstreetmap.org/wiki/State_Of_The_Map_U.S._2014 I'm looking forward to seeing many of you in person at SOTM US 2014 :) Best, Kathleen ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
I think we can divide features to virtual and physical features. Virtual: highway centerlines, waterway centerlines, administrative borders, industrial and residental landuse, parks Physical: riverbanks, buildings, meadows, forests, farm fields Can we make a rule to never share points between these two groups? Janko ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
On Thu, Feb 27, 2014 at 10:57 AM, Janko Mihelić jan...@gmail.com wrote: I think we can divide features to virtual and physical features. Virtual: highway centerlines, waterway centerlines, administrative borders, industrial and residental landuse, parks Physical: riverbanks, buildings, meadows, forests, farm fields Can we make a rule to never share points between these two groups? +1 But we need developer buyin to code this into editors, otherwise new users are going to continue to connect these features. Clifford -- @osm_seattle osm_seattle.snowandsnow.us OpenStreetMap: Maps with a human touch ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] State of the Map US update - schedule is up
Looks like a great line up. While I won't make it there, I look forward to watching the videos. Last year's SOTM-US did a fantastic job with the AV side of things, very professional Dave Message: 6 Date: Thu, 27 Feb 2014 13:47:24 -0500 From: Kathleen Danielson kathleen.daniel...@gmail.com To: OpenStreetMap Talk Mailing List talk@openstreetmap.org Subject: [OSM-talk] State of the Map US update - schedule is up Message-ID: cadx_qxfplw-rc+m5wczumtcvqnnf8d8lh0ima5z-_+r-qdh...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Hi all, SOTM US 2014 is shaping up! The schedule is out now -- http://stateofthemap.us/schedule/ and we also have a blog post with some more info over at openstreetmap.us: http://openstreetmap.us/2014/02/stateofthemap-us-schedule/ If you haven't registered yet, this is a great time to do it, and plan your travel. We have a discounted hotel room deal with the Washington Plaza that is pretty nice, but you need to book before *Mar 11*: http://openstreetmap.us/2014/02/hotel-discount-dc/. We also have a wiki page on the osm.org wiki with sections for ride / room sharing: https://wiki.openstreetmap.org/wiki/State_Of_The_Map_U.S._2014 I'm looking forward to seeing many of you in person at SOTM US 2014 :) Best, Kathleen -- next part -- An HTML attachment was scrubbed... URL: http://lists.openstreetmap.org/pipermail/talk/attachments/20140227/7182896e/attachment.html -- ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
On Thu, Feb 27, 2014 at 10:57 AM, Janko Mihelić jan...@gmail.com wrote: I think we can divide features to virtual and physical features. Virtual: highway centerlines, waterway centerlines, administrative borders, industrial and residental landuse, parks Physical: riverbanks, buildings, meadows, forests, farm fields Can we make a rule to never share points between these two groups? -1. I don't think that grouping is correct. First, centerlines model a physical feature. Second, what you list as physical features are in fact mostly human land uses. Meadows/forests and even riverbanks are constructed and constrained by man. -- Forests and farm field typically abut roads (you may have forest on one side, farm on the other, at the moment). If the road is ever expanded, it will take land from the abutting use. Similarly for a residential land use with a retail land use across the street: there's a dividing line and it's the street. If the road department ever moves the street a few meters, the street will still be the dividing line. Until you get to a level of micromapping that currently covers less than 1% of the planet, the road serves remarkably well as the dividing line. There is no gap on the ground between the forest and the road: at a first level of mapping they abut. --- Perhaps if the editors rendered centerlines with width people would get less uptight about using them as boundaries. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
I suspect that part of the border line is based on rather old and generalised information, most likely traced from the old NPE maps. When I look at the recent boundary information from OS Boundary Line the border is clearly to the east of the road, which would explain why the road markings are bilingual. I will update the boundary in OSM when I get a minute. Colin On 2014-02-27 19:19, Philip Barnes wrote: On Thu, 2014-02-27 at 10:28 -0600, John F. Eldredge wrote: Part of the border of Davidson County in Tennessee, USA runs down the centerline of a road. The village of Llanymynech straddles the England (Shropshire)/Wales (Powis) border, the border runs up the middle of the main street (A483) http://www.openstreetmap.org/#map=16/52.7811/-3.0902 [1] The bi-lingual Slow/Araf markers painted on the road suggest that Powis look after it. Phil (trigpoint) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk [2] Links: -- [1] http://www.openstreetmap.org/#map=16/52.7811/-3.0902 [2] https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
Am 27/feb/2014 um 19:57 schrieb Janko Mihelić jan...@gmail.com: Virtual: highway centerlines, waterway centerlines, administrative borders, industrial and residental landuse, parks Physical: riverbanks, buildings, meadows, forests, farm fields Can we make a rule to never share points between these two groups? When there is a building or a meadow directly attached to a park or a landuse like industrial, they should better have common nodes (to ensure topology), for example, so I think the rule should not be like this. cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
On 27/02/2014, Bryce Nesbitt bry...@obviously.com wrote: On Thu, Feb 27, 2014 at 10:57 AM, Janko Mihelić jan...@gmail.com wrote: I think we can divide features to virtual and physical features. Virtual: highway centerlines, waterway centerlines, administrative borders, industrial and residental landuse, parks Physical: riverbanks, buildings, meadows, forests, farm fields Can we make a rule to never share points between these two groups? -1. I don't think that grouping is correct. First, centerlines model a physical feature. Second, what you list as physical features are in fact mostly human land uses. Meadows/forests and even riverbanks are constructed and constrained by man. That grouping makes sense, except that the terms virtual/physical are really badly chosen. I tend to think of them as 1D/2D or line/area or even simplified/precise. A line can sometimes share nodes with an area, for example a barrier=wall enclosing a natural=wood (assuming the wall is thin enough to be considered as 1D), or a boundary=administrative running along a landuse=meadow. And sometimes it shouldn't, such as a highway=residential along a leisure=park. The rule of thumb is that if a 1D is used as a simplified representation of a 2D object, then it shouldn't share nodes with 2D objects. Editor support for this is tempting, except that it would be fairly complex (lots of rules to figure out 1D from 2D, problems when tags change but not geometry, etc), and that node sharing is not wrong per se, just inaccurate. Once again : sharing nodes is fine, nobody should give out to you if you initially share nodes between a highway and a park. But it's just an approximation/simplification; not sharing nodes (and giving the park its actual shape) is better. And people are entitled to give out if you glue road to a park that was previously accurately mapped. Until you get to a level of micromapping that currently covers less than 1% of the planet, the road serves remarkably well as the dividing line. There is no gap on the ground between the forest and the road: at a first level of mapping they abut. Funny that we generaly agree (there is room for both techniques), but end up marketing opposed viewpoints :) I prefer to only defend and suggest the don't share approach, because it is the one that is ultimately better. If somebody is undecided, I'd rather give him the only technique he'll ever need, rather than giving him two techniques and explaining the subtleties of when to use which. I don't feel that mapping the actual park boundary is micromapping, and your damned li^W^Wstatistics aren't an interesting argument : when I map somewhere, I only care about the desired level of detail, not the current level. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
On 28/02/2014, moltonel 3x Combo molto...@gmail.com wrote: On 27/02/2014, Bryce Nesbitt bry...@obviously.com wrote: On Thu, Feb 27, 2014 at 10:57 AM, Janko Mihelić jan...@gmail.com wrote: Virtual: highway centerlines, waterway centerlines, administrative borders, industrial and residental landuse, parks Physical: riverbanks, buildings, meadows, forests, farm fields That grouping makes sense, except that the terms virtual/physical are really badly chosen. I tend to think of them as 1D/2D or line/area or even simplified/precise. Actually, re-reading the groupings, I'd place landuse for example in the 2nd group, so I retract my the grouping makes sense and propose a different grouping altogether :p ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] SRTM Elevation Data
Is all the 1 sec (30m) SRTM data already imported into OSM? I saw some elevation data, but it looks incomplete so I started trying to blend both data sets. This project is kicking my ass and I need help melding a lat/lon from OSM to SRTM lat/lon. I have both datasets in SQL Server and trying to join them together is the pain point. The pain is either in long query times and/or not accurate enough lookups. I'm finding SQL Server 2012 spatial is slow (it uses .NET). The scope of the project is just the USA data. My server system is: overclocked and water-cooled i7 3930k (4.1GHZ) 6 cores (plus 6 Hyperthreads) 32 GB RAM 1.6GB/s disk IO subsystem and 1/2 TB of space. Speed is as indicated by SQL Server performance monitor. (This can go higher w/more HW RAID controllers that I already have) SQL Server Enterprise Windows Server 2012 Enterprise Ideas from a 30,000' view on how to do this are appreciated (granular views are just as good :) ). Joel ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] SRTM Elevation Data
Am 28.02.2014 02:24, schrieb Joel Znamenacek: Is all the 1 sec (30m) SRTM data already imported into OSM? Don't import the SRTM elevation data to OSM! Instead keep it in another database as the community does this since years. Best regards, Michael. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] Ecoduct
Hi, Wat is de definitie van een Ecoduct ? Is een onderdoorgang dus een brugvormige eco passage ook een Ecoduct ? Als de onder doorgang er bij hoort, mijns inziens juist, dan ontbreken er nog een paar. Onder andere bij Elst (N225), De Bilt (A28), Waterloo (N227) en een tweetal bij Ankeveen (N236) zo los uit de pols maar er zijn er vast meer. Mvg Nick ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Ecoduct
On 2014-02-27 10:15, St Niklaas wrote: Hi, Wat is de definitie van een Ecoduct ? Is een onderdoorgang dus een brugvormige eco passage ook een Ecoduct ? Als de onder doorgang er bij hoort, mijns inziens juist, dan ontbreken er nog een paar. Onder andere bij Elst (N225), De Bilt (A28), Waterloo (N227) en een tweetal bij Ankeveen (N236) zo los uit de pols maar er zijn er vast meer. Ik zou denken dat de benutting van het bruggedeelte zorgt voor de naamgeving. Een aquaduct is een kanaal dat met een brug over een weg gaat. Dus een ecoduct is een ecopassage die met een brug over de weg gaat. Als een weg over een ecopassage gaat is het gewoon een brug. Maarten ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Ecoduct
Beste Maarten, Ik zou denken dat de benutting van het bruggedeelte zorgt voor de naamgeving. Een aquaduct is een kanaal dat met een brug over een weg gaat. Dus een ecoduct is een ecopassage die met een brug over de weg gaat. Als een weg over een ecopassage gaat is het gewoon een brug. Correct. Maar als er slechts een Ecopassage (niet toegankelijk dus jammer en geen pad of weg) onder een kunstwerk ligt is het dan een brug, er ligt geen water onder en is niet beweegbaar, of een viaduct, er ligt ook geen weg onder ! ? Is daarom Ecopassage geen betere woordkeus, zodat we al die punten (passages) in beeld kunnen brengen? Bij het laatste vallen ook de dassen wegen (tunnels) onder het begrip, maar uit natuur behoud moet je die misschien niet taggen. ☹ Mvg Nick ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [Talk-br] Problema de usabilidade do editor de endereços do iD
Por que não usam localização para determinar quais campos mostrar? Qualquer site meia-boca hoje em dia determina seu fuso horário, idioma, moeda, se usa ponto como separador decimal, etc. . Em 26 de fevereiro de 2014 23:38, John Packer john.pack...@gmail.comescreveu: Atualização: O campo addr:housename foi retirado do iD, agora só pode ser incluído manualmente usando etiquetas. Um usuário (não-brasileiro) retirou o campo depois de ver que estava confundindo usuários em outros países. O *pull request* se encontra no seguinte link: https://github.com/openstreetmap/iD/pull/2127 Sugiro agora retirar a tradução de addr:housename como Complemento. Abs, João ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Plugin confaltion do JOSM
+1000 2014-02-26 19:53 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Marcelo, abra um ticket sobre esses problemas: http://josm.openstreetmap.de/newticket Erro de introspecção já é difícil de diagnosticar sendo conhecedor do código, imagine sendo de fora... não trave com isso, passa para frente. Se alguém mais vir esses erros de Java aparecendo, não percam tempo tentando adivinhar, contate os desenvolvedores. Em 26 de fevereiro de 2014 16:53, Marcelo Pereira pereirahol...@gmail.com escreveu: Srs, Desculpem a demora em responder, estava enrolado em achar o Java 6 para instalação. Pois bem. Instalei o Ubuntu do zero, com o java 6. Usei os JOSMs 6502, 6409 e 6296 Sempre com o mesmo erro, consigo até listar os erros encontrados nos mapas, mas na hora de conflacionar, erro!!! Aliás, na versão 6296 o conflation nem carregou, deu pau na inicialização. Se alguem tiver uma combinação JOSM + JAVA funcional, por favor me avise. Ou outra ferramenta que faça a mesma coisa. Agradeço às dicas recebidas, Att, Marcelo Pereira Em 24 de fevereiro de 2014 19:13, Paulo Carvalho paulo.r.m.carva...@gmail.com escreveu: Pode ser mesmo biblioteca incompatível. Agora qual eu não sei. Estou sem condição de investigar isso. Estou com coisas mais fundamentais para investigar como a compilação com mkgmap. Em 24 de fevereiro de 2014 16:31, Fernando Trebien fernando.treb...@gmail.com escreveu: Esses erros de introspecção já foram relatados no bug tracker do plugin, mas o desenvolvedor parece ter meio que abandonado o projeto, ou pelo menos não o estar priorizando (afinal, se funciona com Java 6...). Lembro vagamente de ter lido algum stack trace que sugeria que o erro acontece numa das bibliotecas de que o plugin depende, uma das usadas para calcular a semelhança topológica entre as duas malhas. 2014-02-22 15:22 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Faz sentido usar JOSMs mais antigos. O erro postado pelo Marcelo parece ser um erro de introspecção (erro de funcionamento interno). A grosso modo o plugin não está falando a mesma língua do framework (JOSM). O desenvolvedor do plugin de conflação deve dar uma olhada nas APIs novas e removidas do JOSM. Em 22 de fevereiro de 2014 12:40, Erick de Oliveira Leal erickdeoliveiral...@gmail.com escreveu: Marcelo, vai testando com esses JOSMs mais antigos: http://josm.openstreetmap.de/download/Archiv/ Vai tentando com intervalos de 2 em 2 meses pra ser mais rapido Em 22 de fevereiro de 2014 12:35, Marcelo Pereira pereirahol...@gmail.com escreveu: Erick, Obrigado pela ajuda, segue o erro apresentado ERROR: java.lang.NoSuchMethodError: org.openstreetmap.josm.command.AddPrimitivesCommand.init(Ljava/util/List;Lorg/openstreetmap/josm/gui/layer/OsmDataLayer;)V java.lang.NoSuchMethodError: org.openstreetmap.josm.command.AddPrimitivesCommand.init(Ljava/util/List;Lorg/openstreetmap/josm/gui/layer/OsmDataLayer;)V at org.openstreetmap.josm.plugins.conflation.ConflateMatchCommand.init(ConflateMatchCommand.java:42) at org.openstreetmap.josm.plugins.conflation.ConflationToggleDialog$ConflateAction.conflateMatchActionPerformed(ConflationToggleDialog.java:570) at org.openstreetmap.josm.plugins.conflation.ConflationToggleDialog$ConflateAction.actionPerformed(ConflationToggleDialog.java:547) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2018) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2341) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:252) at java.awt.AWTEventMulticaster.mouseReleased(AWTEventMulticaster.java:289) at java.awt.Component.processMouseEvent(Component.java:6505) at javax.swing.JComponent.processMouseEvent(JComponent.java:3320) at java.awt.Component.processEvent(Component.java:6270) at java.awt.Container.processEvent(Container.java:2229) at java.awt.Component.dispatchEventImpl(Component.java:4861) at java.awt.Container.dispatchEventImpl(Container.java:2287) at java.awt.Component.dispatchEvent(Component.java:4687) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4832) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4492) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4422) at java.awt.Container.dispatchEventImpl(Container.java:2273) at java.awt.Window.dispatchEventImpl(Window.java:2719) at java.awt.Component.dispatchEvent(Component.java:4687) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:735) at java.awt.EventQueue.access$200(EventQueue.java:103) at java.awt.EventQueue$3.run(EventQueue.java:694) at java.awt.EventQueue$3.run(EventQueue.java:692)
Re: [Talk-br] Proposta de padronização de lombadas no Brasil
Acho que a principal diferença entre table e hump é o formato: hump é suave, table é trapezoidal. Independente da extensão. A Wikipédia diz que humps podem ter entre 3m e 4.3m de extensão. 2014-02-26 23:45 GMT-03:00 John Packer john.pack...@gmail.com: Olha, vendo essa etiqueta traffic_calming=table, eu vou segurar a minha proposta por um bom tempo até conseguir investigar melhor essa situação. A pergunta é: existe alguma lombada de 3+ metros que não seja um traffic_calming=table? (ou seja, que não tenha o topo achatado). Sinceramente, nunca vi, e olha que já vi uns 4-5 traffic_calming=tableaqui na minha cidade. Estou pensando que traffic_calming=bump é menor que 1,5m, mas vou tirar umas fotos aqui pra montar melhor o meu caso (isso vai demorar umas duas semanas pelo menos). Quando às depressões, acho que teria que ser proposto uma nova etiqueta ( traffic_calming=depression ou algo assim). Alguém tem uma foto dela? Abs, João Em 25 de fevereiro de 2014 18:46, Arlindo Pereira openstreet...@arlindopereira.com escreveu: Acho que as depressões poderiam ser bump/hump com depression=yes ou algo assim, visto que é a mesma função. Ou propor um valor traffic_calming=depression. O que vocês acham? Tenho essa foto aqui, que não mostra a depressão em si mas dá uma ideia, hehe. Isso foi em Foz do Iguaçu :P Procurar por depressão na pista no Google Imagens retorna resultados semelhantes. :P []s Arlindo 2014-02-25 16:54 GMT-03:00 Marcelo Pereira pereirahol...@gmail.com: Considerações, minhas : - Aqui pros lados do NE tb é conhecida como quebra-molas. - Já vi muitos casos de lombadas feitas pela própria população, nota-se a diferença pela total falta de padrão, mas estas tendem a ser mais altas que as oficiais, já vi até triangulares ( exemplo http://goo.gl/RC3ogE ). Neste caso, que tag usar ? - Já vi lombadas de terra, em vias do mesmo tipo, e aí ? - Aqui perto de casa, tem uma lombada mais larga, que traz no seu corpo uma faixa de pedestres ( exemplo http://goo.gl/16S98g ), como se classificaria isso ? Aproveitando o embalo, não sei se ainda existem, mas cheguei a ver lombadas invertidas, ou seja, depressões na pista usadas como lombadas. Isso recebe tag ? Marcelo Pereira Em 25 de fevereiro de 2014 16:06, Fernando Trebien fernando.treb...@gmail.com escreveu: Por mim tá perfeito. On Feb 25, 2014 3:38 PM, John Packer john.pack...@gmail.com wrote: Pessoal, em uma discussão recente aqui na lista, percebi que tem duas formas diferentes de etiquetar uma lombada: traffic_calming=bump e traffic_calming=hump. Vi que não havia uma padronização quanto a isso no Brasil, então levantei as mangas e comecei a pesquisar. Em primeiro lugar descobri que tem outros nomes para uma lombada: - lomba (que é sinônimo de lombada) - quebra-mola (que é utilizado no RS) - ondulação transversal (que é um termo mais abrangente) E descobri que existem sim dois tipos de lombada: *Tipo I* e *Tipo II*. Como podem ver no seguinte link: http://www.cliqueautomotivo.com.br/index.php?pg=sobrerodas/lombada-ou-quebra-molas O tipo 1 é menor que o tipo 2, mas é também mais curto, forçando o usuário a reduzir mais a velocidade do que no tipo 2. Nas definições de *Bump* que vi, era assim mesmo, com a única diferença sendo que *Bump* poderia ter uma altura maior do que *Hump*em alguns casos. Logo, a minha proposta de padronização é a seguinte: - em lombadas Tipo I = traffic_calming=bump - em lombadas Tipo II = traffic_calming=hump - se não se encaixar em um desses tipos, deve ser etiquetado o mais próximo, de acordo com o *comprimento* Abs, João ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- ... Edileuz, eu não tem nada a ver com Creuza, É mentira da Ivete, não é meu esse caniveete... Halley, Luiz - Poeta, Cantor, Compsitor ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Proposta de padronização de lombadas no Brasil
Aqui no Rio, principalmente em estacionamentos de shoppings, há muitas tables. Em Rio das Ostras, outro local que mapeei recentemente, também tem muitas tables. Em 27 de fevereiro de 2014 11:14, Fernando Trebien fernando.treb...@gmail.com escreveu: Acho que a principal diferença entre table e hump é o formato: hump é suave, table é trapezoidal. Independente da extensão. A Wikipédia diz que humps podem ter entre 3m e 4.3m de extensão. 2014-02-26 23:45 GMT-03:00 John Packer john.pack...@gmail.com: Olha, vendo essa etiqueta traffic_calming=table, eu vou segurar a minha proposta por um bom tempo até conseguir investigar melhor essa situação. A pergunta é: existe alguma lombada de 3+ metros que não seja um traffic_calming=table? (ou seja, que não tenha o topo achatado). Sinceramente, nunca vi, e olha que já vi uns 4-5 traffic_calming=tableaqui na minha cidade. Estou pensando que traffic_calming=bump é menor que 1,5m, mas vou tirar umas fotos aqui pra montar melhor o meu caso (isso vai demorar umas duas semanas pelo menos). Quando às depressões, acho que teria que ser proposto uma nova etiqueta ( traffic_calming=depression ou algo assim). Alguém tem uma foto dela? Abs, João Em 25 de fevereiro de 2014 18:46, Arlindo Pereira openstreet...@arlindopereira.com escreveu: Acho que as depressões poderiam ser bump/hump com depression=yes ou algo assim, visto que é a mesma função. Ou propor um valor traffic_calming=depression. O que vocês acham? Tenho essa foto aqui, que não mostra a depressão em si mas dá uma ideia, hehe. Isso foi em Foz do Iguaçu :P Procurar por depressão na pista no Google Imagens retorna resultados semelhantes. :P []s Arlindo 2014-02-25 16:54 GMT-03:00 Marcelo Pereira pereirahol...@gmail.com: Considerações, minhas : - Aqui pros lados do NE tb é conhecida como quebra-molas. - Já vi muitos casos de lombadas feitas pela própria população, nota-se a diferença pela total falta de padrão, mas estas tendem a ser mais altas que as oficiais, já vi até triangulares ( exemplo http://goo.gl/RC3ogE ). Neste caso, que tag usar ? - Já vi lombadas de terra, em vias do mesmo tipo, e aí ? - Aqui perto de casa, tem uma lombada mais larga, que traz no seu corpo uma faixa de pedestres ( exemplo http://goo.gl/16S98g ), como se classificaria isso ? Aproveitando o embalo, não sei se ainda existem, mas cheguei a ver lombadas invertidas, ou seja, depressões na pista usadas como lombadas. Isso recebe tag ? Marcelo Pereira Em 25 de fevereiro de 2014 16:06, Fernando Trebien fernando.treb...@gmail.com escreveu: Por mim tá perfeito. On Feb 25, 2014 3:38 PM, John Packer john.pack...@gmail.com wrote: Pessoal, em uma discussão recente aqui na lista, percebi que tem duas formas diferentes de etiquetar uma lombada: traffic_calming=bump e traffic_calming=hump. Vi que não havia uma padronização quanto a isso no Brasil, então levantei as mangas e comecei a pesquisar. Em primeiro lugar descobri que tem outros nomes para uma lombada: - lomba (que é sinônimo de lombada) - quebra-mola (que é utilizado no RS) - ondulação transversal (que é um termo mais abrangente) E descobri que existem sim dois tipos de lombada: *Tipo I* e *Tipo II*. Como podem ver no seguinte link: http://www.cliqueautomotivo.com.br/index.php?pg=sobrerodas/lombada-ou-quebra-molas O tipo 1 é menor que o tipo 2, mas é também mais curto, forçando o usuário a reduzir mais a velocidade do que no tipo 2. Nas definições de *Bump* que vi, era assim mesmo, com a única diferença sendo que *Bump* poderia ter uma altura maior do que *Hump*em alguns casos. Logo, a minha proposta de padronização é a seguinte: - em lombadas Tipo I = traffic_calming=bump - em lombadas Tipo II = traffic_calming=hump - se não se encaixar em um desses tipos, deve ser etiquetado o mais próximo, de acordo com o *comprimento* Abs, João ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- ... Edileuz, eu não tem nada a ver com Creuza, É mentira da Ivete, não é meu esse caniveete... Halley, Luiz - Poeta, Cantor, Compsitor ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves
Re: [Talk-br] Proposta de padronização de lombadas no Brasil
Não sei. Acho que table é outra coisa. (Importante mencionar que eu não dirijo, ok? Minha impressão é meramente pela observação das ruas.) Pra mim, table é isso: http://www.ite.org/css/online/img/Figure9-17.jpg http://www.cyclestreets.net/location/47587/cyclestreets47587-size640.jpg http://wiki.coe.neu.edu/groups/nl2011transpo/wiki/5e21c/images/__thumbs__/3ffdd.jpg http://2.bp.blogspot.com/-gIoeIhSgaP0/UZu8XGmSnHI/AeU/-c2c-BT2BPs/s1600/Elwick+Road,+Ashford.jpg http://2.bp.blogspot.com/_nqmNLgL2k80/TOV5_AuWSNI/Bao/ptlW4H6I62w/s1600/12457.jpg http://3.bp.blogspot.com/-eZhsiJXAbQA/TdhHhRQKSgI/Aps/DbPwZtSzspw/s1600/San+Telmo+-+Chile.jpg Em resumo, via de regra utilizados em travessias de pedestres aonde não há uma rampa da calçada para o nível do asfalto, mas sim o inverso, uma rampa do asfalto para o nível da calçada. []s Arlindo 2014-02-27 11:14 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Acho que a principal diferença entre table e hump é o formato: hump é suave, table é trapezoidal. Independente da extensão. A Wikipédia diz que humps podem ter entre 3m e 4.3m de extensão. 2014-02-26 23:45 GMT-03:00 John Packer john.pack...@gmail.com: Olha, vendo essa etiqueta traffic_calming=table, eu vou segurar a minha proposta por um bom tempo até conseguir investigar melhor essa situação. A pergunta é: existe alguma lombada de 3+ metros que não seja um traffic_calming=table? (ou seja, que não tenha o topo achatado). Sinceramente, nunca vi, e olha que já vi uns 4-5 traffic_calming=tableaqui na minha cidade. Estou pensando que traffic_calming=bump é menor que 1,5m, mas vou tirar umas fotos aqui pra montar melhor o meu caso (isso vai demorar umas duas semanas pelo menos). Quando às depressões, acho que teria que ser proposto uma nova etiqueta ( traffic_calming=depression ou algo assim). Alguém tem uma foto dela? Abs, João Em 25 de fevereiro de 2014 18:46, Arlindo Pereira openstreet...@arlindopereira.com escreveu: Acho que as depressões poderiam ser bump/hump com depression=yes ou algo assim, visto que é a mesma função. Ou propor um valor traffic_calming=depression. O que vocês acham? Tenho essa foto aqui, que não mostra a depressão em si mas dá uma ideia, hehe. Isso foi em Foz do Iguaçu :P Procurar por depressão na pista no Google Imagens retorna resultados semelhantes. :P []s Arlindo 2014-02-25 16:54 GMT-03:00 Marcelo Pereira pereirahol...@gmail.com: Considerações, minhas : - Aqui pros lados do NE tb é conhecida como quebra-molas. - Já vi muitos casos de lombadas feitas pela própria população, nota-se a diferença pela total falta de padrão, mas estas tendem a ser mais altas que as oficiais, já vi até triangulares ( exemplo http://goo.gl/RC3ogE ). Neste caso, que tag usar ? - Já vi lombadas de terra, em vias do mesmo tipo, e aí ? - Aqui perto de casa, tem uma lombada mais larga, que traz no seu corpo uma faixa de pedestres ( exemplo http://goo.gl/16S98g ), como se classificaria isso ? Aproveitando o embalo, não sei se ainda existem, mas cheguei a ver lombadas invertidas, ou seja, depressões na pista usadas como lombadas. Isso recebe tag ? Marcelo Pereira Em 25 de fevereiro de 2014 16:06, Fernando Trebien fernando.treb...@gmail.com escreveu: Por mim tá perfeito. On Feb 25, 2014 3:38 PM, John Packer john.pack...@gmail.com wrote: Pessoal, em uma discussão recente aqui na lista, percebi que tem duas formas diferentes de etiquetar uma lombada: traffic_calming=bump e traffic_calming=hump. Vi que não havia uma padronização quanto a isso no Brasil, então levantei as mangas e comecei a pesquisar. Em primeiro lugar descobri que tem outros nomes para uma lombada: - lomba (que é sinônimo de lombada) - quebra-mola (que é utilizado no RS) - ondulação transversal (que é um termo mais abrangente) E descobri que existem sim dois tipos de lombada: *Tipo I* e *Tipo II*. Como podem ver no seguinte link: http://www.cliqueautomotivo.com.br/index.php?pg=sobrerodas/lombada-ou-quebra-molas O tipo 1 é menor que o tipo 2, mas é também mais curto, forçando o usuário a reduzir mais a velocidade do que no tipo 2. Nas definições de *Bump* que vi, era assim mesmo, com a única diferença sendo que *Bump* poderia ter uma altura maior do que *Hump*em alguns casos. Logo, a minha proposta de padronização é a seguinte: - em lombadas Tipo I = traffic_calming=bump - em lombadas Tipo II = traffic_calming=hump - se não se encaixar em um desses tipos, deve ser etiquetado o mais próximo, de acordo com o *comprimento* Abs, João ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- ... Edileuz, eu não tem nada a ver com Creuza, É
Re: [Talk-br] Problema de usabilidade do editor de endereços do iD
Retiramos, será? Eu ainda acho que essa tag é o que mais se aproxima do nosso complemento, e que as outras tags não são amplamente suportadas, e que não faz diferença usar as outras ou essa. Os presets de endereço do JOSM ainda incluem esse campo, e não incluem os outros (addr:door, addr:unit, etc.). 2014-02-26 23:38 GMT-03:00 John Packer john.pack...@gmail.com: Atualização: O campo addr:housename foi retirado do iD, agora só pode ser incluído manualmente usando etiquetas. Um usuário (não-brasileiro) retirou o campo depois de ver que estava confundindo usuários em outros países. O pull request se encontra no seguinte link: https://github.com/openstreetmap/iD/pull/2127 Sugiro agora retirar a tradução de addr:housename como Complemento. Abs, João ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Proposta de padronização de lombadas no Brasil
(Acabei mandando antes) Portanto, table seria esse tipo de travessia específica e bump e hump quebra-molas/lombadas, sendo bump o quebra-mola tradicional e hump um tipo de quebra-mola que só seria utilizado em estradas federais ou estaduais. Não há tag para quebra-molas irregulares/ilegais/menores que o tamanho padrão. Podemos propor uma. Mas não acho legal subverter o significado de bump para isso. Talvez dangerous_bump ou bump + irregular=yes ou illegal=yes ou algo do tipo. []s Arlindo 2014-02-27 11:21 GMT-03:00 Arlindo Pereira openstreet...@arlindopereira.com : Não sei. Acho que table é outra coisa. (Importante mencionar que eu não dirijo, ok? Minha impressão é meramente pela observação das ruas.) Pra mim, table é isso: http://www.ite.org/css/online/img/Figure9-17.jpg http://www.cyclestreets.net/location/47587/cyclestreets47587-size640.jpg http://wiki.coe.neu.edu/groups/nl2011transpo/wiki/5e21c/images/__thumbs__/3ffdd.jpg http://2.bp.blogspot.com/-gIoeIhSgaP0/UZu8XGmSnHI/AeU/-c2c-BT2BPs/s1600/Elwick+Road,+Ashford.jpg http://2.bp.blogspot.com/_nqmNLgL2k80/TOV5_AuWSNI/Bao/ptlW4H6I62w/s1600/12457.jpg http://3.bp.blogspot.com/-eZhsiJXAbQA/TdhHhRQKSgI/Aps/DbPwZtSzspw/s1600/San+Telmo+-+Chile.jpg Em resumo, via de regra utilizados em travessias de pedestres aonde não há uma rampa da calçada para o nível do asfalto, mas sim o inverso, uma rampa do asfalto para o nível da calçada. []s Arlindo 2014-02-27 11:14 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Acho que a principal diferença entre table e hump é o formato: hump é suave, table é trapezoidal. Independente da extensão. A Wikipédia diz que humps podem ter entre 3m e 4.3m de extensão. 2014-02-26 23:45 GMT-03:00 John Packer john.pack...@gmail.com: Olha, vendo essa etiqueta traffic_calming=table, eu vou segurar a minha proposta por um bom tempo até conseguir investigar melhor essa situação. A pergunta é: existe alguma lombada de 3+ metros que não seja um traffic_calming=table? (ou seja, que não tenha o topo achatado). Sinceramente, nunca vi, e olha que já vi uns 4-5 traffic_calming=tableaqui na minha cidade. Estou pensando que traffic_calming=bump é menor que 1,5m, mas vou tirar umas fotos aqui pra montar melhor o meu caso (isso vai demorar umas duas semanas pelo menos). Quando às depressões, acho que teria que ser proposto uma nova etiqueta ( traffic_calming=depression ou algo assim). Alguém tem uma foto dela? Abs, João Em 25 de fevereiro de 2014 18:46, Arlindo Pereira openstreet...@arlindopereira.com escreveu: Acho que as depressões poderiam ser bump/hump com depression=yes ou algo assim, visto que é a mesma função. Ou propor um valor traffic_calming=depression. O que vocês acham? Tenho essa foto aqui, que não mostra a depressão em si mas dá uma ideia, hehe. Isso foi em Foz do Iguaçu :P Procurar por depressão na pista no Google Imagens retorna resultados semelhantes. :P []s Arlindo 2014-02-25 16:54 GMT-03:00 Marcelo Pereira pereirahol...@gmail.com: Considerações, minhas : - Aqui pros lados do NE tb é conhecida como quebra-molas. - Já vi muitos casos de lombadas feitas pela própria população, nota-se a diferença pela total falta de padrão, mas estas tendem a ser mais altas que as oficiais, já vi até triangulares ( exemplo http://goo.gl/RC3ogE ). Neste caso, que tag usar ? - Já vi lombadas de terra, em vias do mesmo tipo, e aí ? - Aqui perto de casa, tem uma lombada mais larga, que traz no seu corpo uma faixa de pedestres ( exemplo http://goo.gl/16S98g ), como se classificaria isso ? Aproveitando o embalo, não sei se ainda existem, mas cheguei a ver lombadas invertidas, ou seja, depressões na pista usadas como lombadas. Isso recebe tag ? Marcelo Pereira Em 25 de fevereiro de 2014 16:06, Fernando Trebien fernando.treb...@gmail.com escreveu: Por mim tá perfeito. On Feb 25, 2014 3:38 PM, John Packer john.pack...@gmail.com wrote: Pessoal, em uma discussão recente aqui na lista, percebi que tem duas formas diferentes de etiquetar uma lombada: traffic_calming=bump e traffic_calming=hump. Vi que não havia uma padronização quanto a isso no Brasil, então levantei as mangas e comecei a pesquisar. Em primeiro lugar descobri que tem outros nomes para uma lombada: - lomba (que é sinônimo de lombada) - quebra-mola (que é utilizado no RS) - ondulação transversal (que é um termo mais abrangente) E descobri que existem sim dois tipos de lombada: *Tipo I* e *Tipo II*. Como podem ver no seguinte link: http://www.cliqueautomotivo.com.br/index.php?pg=sobrerodas/lombada-ou-quebra-molas O tipo 1 é menor que o tipo 2, mas é também mais curto, forçando o usuário a reduzir mais a velocidade do que no tipo 2. Nas definições de *Bump* que vi, era assim mesmo, com a única diferença sendo que *Bump* poderia ter uma altura maior do que *Hump* em alguns casos. Logo, a minha proposta de padronização é a
Re: [Talk-br] Proposta de padronização de lombadas no Brasil
Elas ocorrem em travessias de pedestre, mas pelo que diz na Wikipédia, não só nessa situação. http://en.wikipedia.org/wiki/Vertical_deflection_traffic_calming_device#Speed_tables Talvez no Brasil seja só nessa situação. Além disso, acho que tables não são chamadas de lombadas no Brasil. 2014-02-27 11:23 GMT-03:00 Arlindo Pereira openstreet...@arlindopereira.com : (Acabei mandando antes) Portanto, table seria esse tipo de travessia específica e bump e hump quebra-molas/lombadas, sendo bump o quebra-mola tradicional e hump um tipo de quebra-mola que só seria utilizado em estradas federais ou estaduais. Não há tag para quebra-molas irregulares/ilegais/menores que o tamanho padrão. Podemos propor uma. Mas não acho legal subverter o significado de bump para isso. Talvez dangerous_bump ou bump + irregular=yes ou illegal=yes ou algo do tipo. []s Arlindo 2014-02-27 11:21 GMT-03:00 Arlindo Pereira openstreet...@arlindopereira.com: Não sei. Acho que table é outra coisa. (Importante mencionar que eu não dirijo, ok? Minha impressão é meramente pela observação das ruas.) Pra mim, table é isso: http://www.ite.org/css/online/img/Figure9-17.jpg http://www.cyclestreets.net/location/47587/cyclestreets47587-size640.jpg http://wiki.coe.neu.edu/groups/nl2011transpo/wiki/5e21c/images/__thumbs__/3ffdd.jpg http://2.bp.blogspot.com/-gIoeIhSgaP0/UZu8XGmSnHI/AeU/-c2c-BT2BPs/s1600/Elwick+Road,+Ashford.jpg http://2.bp.blogspot.com/_nqmNLgL2k80/TOV5_AuWSNI/Bao/ptlW4H6I62w/s1600/12457.jpg http://3.bp.blogspot.com/-eZhsiJXAbQA/TdhHhRQKSgI/Aps/DbPwZtSzspw/s1600/San+Telmo+-+Chile.jpg Em resumo, via de regra utilizados em travessias de pedestres aonde não há uma rampa da calçada para o nível do asfalto, mas sim o inverso, uma rampa do asfalto para o nível da calçada. []s Arlindo 2014-02-27 11:14 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Acho que a principal diferença entre table e hump é o formato: hump é suave, table é trapezoidal. Independente da extensão. A Wikipédia diz que humps podem ter entre 3m e 4.3m de extensão. 2014-02-26 23:45 GMT-03:00 John Packer john.pack...@gmail.com: Olha, vendo essa etiqueta traffic_calming=table, eu vou segurar a minha proposta por um bom tempo até conseguir investigar melhor essa situação. A pergunta é: existe alguma lombada de 3+ metros que não seja um traffic_calming=table? (ou seja, que não tenha o topo achatado). Sinceramente, nunca vi, e olha que já vi uns 4-5 traffic_calming=tableaqui na minha cidade. Estou pensando que traffic_calming=bump é menor que 1,5m, mas vou tirar umas fotos aqui pra montar melhor o meu caso (isso vai demorar umas duas semanas pelo menos). Quando às depressões, acho que teria que ser proposto uma nova etiqueta (traffic_calming=depression ou algo assim). Alguém tem uma foto dela? Abs, João Em 25 de fevereiro de 2014 18:46, Arlindo Pereira openstreet...@arlindopereira.com escreveu: Acho que as depressões poderiam ser bump/hump com depression=yes ou algo assim, visto que é a mesma função. Ou propor um valor traffic_calming=depression. O que vocês acham? Tenho essa foto aqui, que não mostra a depressão em si mas dá uma ideia, hehe. Isso foi em Foz do Iguaçu :P Procurar por depressão na pista no Google Imagens retorna resultados semelhantes. :P []s Arlindo 2014-02-25 16:54 GMT-03:00 Marcelo Pereira pereirahol...@gmail.com: Considerações, minhas : - Aqui pros lados do NE tb é conhecida como quebra-molas. - Já vi muitos casos de lombadas feitas pela própria população, nota-se a diferença pela total falta de padrão, mas estas tendem a ser mais altas que as oficiais, já vi até triangulares ( exemplo http://goo.gl/RC3ogE ). Neste caso, que tag usar ? - Já vi lombadas de terra, em vias do mesmo tipo, e aí ? - Aqui perto de casa, tem uma lombada mais larga, que traz no seu corpo uma faixa de pedestres ( exemplo http://goo.gl/16S98g ), como se classificaria isso ? Aproveitando o embalo, não sei se ainda existem, mas cheguei a ver lombadas invertidas, ou seja, depressões na pista usadas como lombadas. Isso recebe tag ? Marcelo Pereira Em 25 de fevereiro de 2014 16:06, Fernando Trebien fernando.treb...@gmail.com escreveu: Por mim tá perfeito. On Feb 25, 2014 3:38 PM, John Packer john.pack...@gmail.com wrote: Pessoal, em uma discussão recente aqui na lista, percebi que tem duas formas diferentes de etiquetar uma lombada: traffic_calming=bump e traffic_calming=hump. Vi que não havia uma padronização quanto a isso no Brasil, então levantei as mangas e comecei a pesquisar. Em primeiro lugar descobri que tem outros nomes para uma lombada: - lomba (que é sinônimo de lombada) - quebra-mola (que é utilizado no RS) - ondulação transversal (que é um termo mais abrangente) E descobri que existem sim dois tipos de lombada: *Tipo I* e *Tipo II*. Como podem ver no seguinte link:
Re: [Talk-br] Problema de usabilidade do editor de endereços do iD
2014-02-27 11:22 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Os presets de endereço do JOSM ainda incluem esse campo, e não incluem os outros (addr:door, addr:unit, etc.). Qual preset que cria addr:housename? ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Problema de usabilidade do editor de endereços do iD
Annotation/Addresses (inglês) ou Endereços e Contactos/Endereços (português de Portugal) ou Anotação/Endereços (português brasileiro). 2014-02-27 11:30 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com: 2014-02-27 11:22 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Os presets de endereço do JOSM ainda incluem esse campo, e não incluem os outros (addr:door, addr:unit, etc.). Qual preset que cria addr:housename? ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Proposta de padronização de lombadas no Brasil
Não há tag para quebra-molas irregulares/ilegais/menores que o tamanho padrão. Podemos propor uma. Mas não acho legal subverter o significado de bump para isso. Talvez dangerous_bump ou bump + irregular=yes ou illegal=yes ou algo do tipo. É verdade, não posso negar que *bump* se encaixem bem com lombadas Tipo I. Seria bom ter como etiquetar lombadas irregulares, tanto porquê não é tão incomum assim, mas acho que não seja tão fácil fazer isso de forma objetiva(fora colocar height=* e length=*(respectivamente altura e comprimento), que exige um bom esforço). Portanto, table seria esse tipo de travessia específica e bump e hump quebra-molas/lombadas, sendo bump o quebra-mola tradicional e hump um tipo de quebra-mola que só seria utilizado em estradas federais ou estaduais. Você já viu lombadas Tipo II (que tem 3+ metros de comprimento) em estradas federais ou estaduais no Brasil? Em 27 de fevereiro de 2014 11:23, Arlindo Pereira openstreet...@arlindopereira.com escreveu: (Acabei mandando antes) Portanto, table seria esse tipo de travessia específica e bump e hump quebra-molas/lombadas, sendo bump o quebra-mola tradicional e hump um tipo de quebra-mola que só seria utilizado em estradas federais ou estaduais. Não há tag para quebra-molas irregulares/ilegais/menores que o tamanho padrão. Podemos propor uma. Mas não acho legal subverter o significado de bump para isso. Talvez dangerous_bump ou bump + irregular=yes ou illegal=yes ou algo do tipo. []s Arlindo 2014-02-27 11:21 GMT-03:00 Arlindo Pereira openstreet...@arlindopereira.com: Não sei. Acho que table é outra coisa. (Importante mencionar que eu não dirijo, ok? Minha impressão é meramente pela observação das ruas.) Pra mim, table é isso: http://www.ite.org/css/online/img/Figure9-17.jpg http://www.cyclestreets.net/location/47587/cyclestreets47587-size640.jpg http://wiki.coe.neu.edu/groups/nl2011transpo/wiki/5e21c/images/__thumbs__/3ffdd.jpg http://2.bp.blogspot.com/-gIoeIhSgaP0/UZu8XGmSnHI/AeU/-c2c-BT2BPs/s1600/Elwick+Road,+Ashford.jpg http://2.bp.blogspot.com/_nqmNLgL2k80/TOV5_AuWSNI/Bao/ptlW4H6I62w/s1600/12457.jpg http://3.bp.blogspot.com/-eZhsiJXAbQA/TdhHhRQKSgI/Aps/DbPwZtSzspw/s1600/San+Telmo+-+Chile.jpg Em resumo, via de regra utilizados em travessias de pedestres aonde não há uma rampa da calçada para o nível do asfalto, mas sim o inverso, uma rampa do asfalto para o nível da calçada. []s Arlindo 2014-02-27 11:14 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Acho que a principal diferença entre table e hump é o formato: hump é suave, table é trapezoidal. Independente da extensão. A Wikipédia diz que humps podem ter entre 3m e 4.3m de extensão. 2014-02-26 23:45 GMT-03:00 John Packer john.pack...@gmail.com: Olha, vendo essa etiqueta traffic_calming=table, eu vou segurar a minha proposta por um bom tempo até conseguir investigar melhor essa situação. A pergunta é: existe alguma lombada de 3+ metros que não seja um traffic_calming=table? (ou seja, que não tenha o topo achatado). Sinceramente, nunca vi, e olha que já vi uns 4-5 traffic_calming=tableaqui na minha cidade. Estou pensando que traffic_calming=bump é menor que 1,5m, mas vou tirar umas fotos aqui pra montar melhor o meu caso (isso vai demorar umas duas semanas pelo menos). Quando às depressões, acho que teria que ser proposto uma nova etiqueta (traffic_calming=depression ou algo assim). Alguém tem uma foto dela? Abs, João Em 25 de fevereiro de 2014 18:46, Arlindo Pereira openstreet...@arlindopereira.com escreveu: Acho que as depressões poderiam ser bump/hump com depression=yes ou algo assim, visto que é a mesma função. Ou propor um valor traffic_calming=depression. O que vocês acham? Tenho essa foto aqui, que não mostra a depressão em si mas dá uma ideia, hehe. Isso foi em Foz do Iguaçu :P Procurar por depressão na pista no Google Imagens retorna resultados semelhantes. :P []s Arlindo 2014-02-25 16:54 GMT-03:00 Marcelo Pereira pereirahol...@gmail.com: Considerações, minhas : - Aqui pros lados do NE tb é conhecida como quebra-molas. - Já vi muitos casos de lombadas feitas pela própria população, nota-se a diferença pela total falta de padrão, mas estas tendem a ser mais altas que as oficiais, já vi até triangulares ( exemplo http://goo.gl/RC3ogE ). Neste caso, que tag usar ? - Já vi lombadas de terra, em vias do mesmo tipo, e aí ? - Aqui perto de casa, tem uma lombada mais larga, que traz no seu corpo uma faixa de pedestres ( exemplo http://goo.gl/16S98g ), como se classificaria isso ? Aproveitando o embalo, não sei se ainda existem, mas cheguei a ver lombadas invertidas, ou seja, depressões na pista usadas como lombadas. Isso recebe tag ? Marcelo Pereira Em 25 de fevereiro de 2014 16:06, Fernando Trebien fernando.treb...@gmail.com escreveu: Por mim tá perfeito. On Feb 25, 2014 3:38 PM, John Packer john.pack...@gmail.com
Re: [Talk-br] Proposta de padronização de lombadas no Brasil
Amigos, Descobri qual é o termo brasileiro para traffic_calming=table. É Travessia Elevada. Com isso, acredito que os nós da proposta fecham. Farei uma página de desambiguação na wiki chamada Lombada, e redirecionar os links traffic_calming=bump, traffic_calming=hump e traffic_calming=tablepara essa página. Também adicionarei os seguintes termos na página de referência de traduções: - *Bump* = Lombada Tipo I - *Hump* = Lombada Tipo II - *Table (traffic calming)* = Travessia Elevada E classificarei essas traduções como literais. (isso tudo assim que tiver tempo) Em 27 de fevereiro de 2014 11:28, Fernando Trebien fernando.treb...@gmail.com escreveu: Elas ocorrem em travessias de pedestre, mas pelo que diz na Wikipédia, não só nessa situação. http://en.wikipedia.org/wiki/Vertical_deflection_traffic_calming_device#Speed_tables Talvez no Brasil seja só nessa situação. Além disso, acho que tables não são chamadas de lombadas no Brasil. 2014-02-27 11:23 GMT-03:00 Arlindo Pereira openstreet...@arlindopereira.com: (Acabei mandando antes) Portanto, table seria esse tipo de travessia específica e bump e hump quebra-molas/lombadas, sendo bump o quebra-mola tradicional e hump um tipo de quebra-mola que só seria utilizado em estradas federais ou estaduais. Não há tag para quebra-molas irregulares/ilegais/menores que o tamanho padrão. Podemos propor uma. Mas não acho legal subverter o significado de bump para isso. Talvez dangerous_bump ou bump + irregular=yes ou illegal=yes ou algo do tipo. []s Arlindo 2014-02-27 11:21 GMT-03:00 Arlindo Pereira openstreet...@arlindopereira.com: Não sei. Acho que table é outra coisa. (Importante mencionar que eu não dirijo, ok? Minha impressão é meramente pela observação das ruas.) Pra mim, table é isso: http://www.ite.org/css/online/img/Figure9-17.jpg http://www.cyclestreets.net/location/47587/cyclestreets47587-size640.jpg http://wiki.coe.neu.edu/groups/nl2011transpo/wiki/5e21c/images/__thumbs__/3ffdd.jpg http://2.bp.blogspot.com/-gIoeIhSgaP0/UZu8XGmSnHI/AeU/-c2c-BT2BPs/s1600/Elwick+Road,+Ashford.jpg http://2.bp.blogspot.com/_nqmNLgL2k80/TOV5_AuWSNI/Bao/ptlW4H6I62w/s1600/12457.jpg http://3.bp.blogspot.com/-eZhsiJXAbQA/TdhHhRQKSgI/Aps/DbPwZtSzspw/s1600/San+Telmo+-+Chile.jpg Em resumo, via de regra utilizados em travessias de pedestres aonde não há uma rampa da calçada para o nível do asfalto, mas sim o inverso, uma rampa do asfalto para o nível da calçada. []s Arlindo 2014-02-27 11:14 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com : Acho que a principal diferença entre table e hump é o formato: hump é suave, table é trapezoidal. Independente da extensão. A Wikipédia diz que humps podem ter entre 3m e 4.3m de extensão. 2014-02-26 23:45 GMT-03:00 John Packer john.pack...@gmail.com: Olha, vendo essa etiqueta traffic_calming=table, eu vou segurar a minha proposta por um bom tempo até conseguir investigar melhor essa situação. A pergunta é: existe alguma lombada de 3+ metros que não seja um traffic_calming=table? (ou seja, que não tenha o topo achatado). Sinceramente, nunca vi, e olha que já vi uns 4-5 traffic_calming=tableaqui na minha cidade. Estou pensando que traffic_calming=bump é menor que 1,5m, mas vou tirar umas fotos aqui pra montar melhor o meu caso (isso vai demorar umas duas semanas pelo menos). Quando às depressões, acho que teria que ser proposto uma nova etiqueta (traffic_calming=depression ou algo assim). Alguém tem uma foto dela? Abs, João Em 25 de fevereiro de 2014 18:46, Arlindo Pereira openstreet...@arlindopereira.com escreveu: Acho que as depressões poderiam ser bump/hump com depression=yes ou algo assim, visto que é a mesma função. Ou propor um valor traffic_calming=depression. O que vocês acham? Tenho essa foto aqui, que não mostra a depressão em si mas dá uma ideia, hehe. Isso foi em Foz do Iguaçu :P Procurar por depressão na pista no Google Imagens retorna resultados semelhantes. :P []s Arlindo 2014-02-25 16:54 GMT-03:00 Marcelo Pereira pereirahol...@gmail.com: Considerações, minhas : - Aqui pros lados do NE tb é conhecida como quebra-molas. - Já vi muitos casos de lombadas feitas pela própria população, nota-se a diferença pela total falta de padrão, mas estas tendem a ser mais altas que as oficiais, já vi até triangulares ( exemplo http://goo.gl/RC3ogE ). Neste caso, que tag usar ? - Já vi lombadas de terra, em vias do mesmo tipo, e aí ? - Aqui perto de casa, tem uma lombada mais larga, que traz no seu corpo uma faixa de pedestres ( exemplo http://goo.gl/16S98g ), como se classificaria isso ? Aproveitando o embalo, não sei se ainda existem, mas cheguei a ver lombadas invertidas, ou seja, depressões na pista usadas como lombadas. Isso recebe tag ? Marcelo Pereira Em 25 de fevereiro de 2014 16:06, Fernando Trebien fernando.treb...@gmail.com escreveu: Por mim tá perfeito. On
Re: [Talk-br] Proposta de padronização de lombadas no Brasil
Sugestão: ao colocar as traduções, coloque também a fonte delas. Por exemplo, onde você descobriu que table é travessia elevada, foi alguma fonte oficial? Mais adiante, pode ser necessário saber. Eu ainda acho que table pode existir em lugares que não são travessias. Mas se a definição desse termo oficialmente (dada por algum Detran ou pelo DNIT ou pelo CTB) permitir essa interpretação, então traduziremos assim. 2014-02-27 12:28 GMT-03:00 John Packer john.pack...@gmail.com: Amigos, Descobri qual é o termo brasileiro para traffic_calming=table. É Travessia Elevada. Com isso, acredito que os nós da proposta fecham. Farei uma página de desambiguação na wiki chamada Lombada, e redirecionar os links traffic_calming=bump, traffic_calming=hump e traffic_calming=table para essa página. Também adicionarei os seguintes termos na página de referência de traduções: - *Bump* = Lombada Tipo I - *Hump* = Lombada Tipo II - *Table (traffic calming)* = Travessia Elevada E classificarei essas traduções como literais. (isso tudo assim que tiver tempo) Em 27 de fevereiro de 2014 11:28, Fernando Trebien fernando.treb...@gmail.com escreveu: Elas ocorrem em travessias de pedestre, mas pelo que diz na Wikipédia, não só nessa situação. http://en.wikipedia.org/wiki/Vertical_deflection_traffic_calming_device#Speed_tables Talvez no Brasil seja só nessa situação. Além disso, acho que tables não são chamadas de lombadas no Brasil. 2014-02-27 11:23 GMT-03:00 Arlindo Pereira openstreet...@arlindopereira.com: (Acabei mandando antes) Portanto, table seria esse tipo de travessia específica e bump e hump quebra-molas/lombadas, sendo bump o quebra-mola tradicional e hump um tipo de quebra-mola que só seria utilizado em estradas federais ou estaduais. Não há tag para quebra-molas irregulares/ilegais/menores que o tamanho padrão. Podemos propor uma. Mas não acho legal subverter o significado de bump para isso. Talvez dangerous_bump ou bump + irregular=yes ou illegal=yes ou algo do tipo. []s Arlindo 2014-02-27 11:21 GMT-03:00 Arlindo Pereira openstreet...@arlindopereira.com: Não sei. Acho que table é outra coisa. (Importante mencionar que eu não dirijo, ok? Minha impressão é meramente pela observação das ruas.) Pra mim, table é isso: http://www.ite.org/css/online/img/Figure9-17.jpg http://www.cyclestreets.net/location/47587/cyclestreets47587-size640.jpg http://wiki.coe.neu.edu/groups/nl2011transpo/wiki/5e21c/images/__thumbs__/3ffdd.jpg http://2.bp.blogspot.com/-gIoeIhSgaP0/UZu8XGmSnHI/AeU/-c2c-BT2BPs/s1600/Elwick+Road,+Ashford.jpg http://2.bp.blogspot.com/_nqmNLgL2k80/TOV5_AuWSNI/Bao/ptlW4H6I62w/s1600/12457.jpg http://3.bp.blogspot.com/-eZhsiJXAbQA/TdhHhRQKSgI/Aps/DbPwZtSzspw/s1600/San+Telmo+-+Chile.jpg Em resumo, via de regra utilizados em travessias de pedestres aonde não há uma rampa da calçada para o nível do asfalto, mas sim o inverso, uma rampa do asfalto para o nível da calçada. []s Arlindo 2014-02-27 11:14 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com : Acho que a principal diferença entre table e hump é o formato: hump é suave, table é trapezoidal. Independente da extensão. A Wikipédia diz que humps podem ter entre 3m e 4.3m de extensão. 2014-02-26 23:45 GMT-03:00 John Packer john.pack...@gmail.com: Olha, vendo essa etiqueta traffic_calming=table, eu vou segurar a minha proposta por um bom tempo até conseguir investigar melhor essa situação. A pergunta é: existe alguma lombada de 3+ metros que não seja um traffic_calming=table? (ou seja, que não tenha o topo achatado). Sinceramente, nunca vi, e olha que já vi uns 4-5 traffic_calming=table aqui na minha cidade. Estou pensando que traffic_calming=bump é menor que 1,5m, mas vou tirar umas fotos aqui pra montar melhor o meu caso (isso vai demorar umas duas semanas pelo menos). Quando às depressões, acho que teria que ser proposto uma nova etiqueta (traffic_calming=depression ou algo assim). Alguém tem uma foto dela? Abs, João Em 25 de fevereiro de 2014 18:46, Arlindo Pereira openstreet...@arlindopereira.com escreveu: Acho que as depressões poderiam ser bump/hump com depression=yes ou algo assim, visto que é a mesma função. Ou propor um valor traffic_calming=depression. O que vocês acham? Tenho essa foto aqui, que não mostra a depressão em si mas dá uma ideia, hehe. Isso foi em Foz do Iguaçu :P Procurar por depressão na pista no Google Imagens retorna resultados semelhantes. :P []s Arlindo 2014-02-25 16:54 GMT-03:00 Marcelo Pereira pereirahol...@gmail.com : Considerações, minhas : - Aqui pros lados do NE tb é conhecida como quebra-molas. - Já vi muitos casos de lombadas feitas pela própria população, nota-se a diferença pela total falta de padrão, mas estas tendem a ser mais altas que as oficiais, já vi até triangulares ( exemplo http://goo.gl/RC3ogE ). Neste caso, que tag usar ? - Já vi lombadas
Re: [Talk-br] Proposta de padronização de lombadas no Brasil
Sugestão: ao colocar as traduções, coloque também a fonte delas. Por exemplo, onde você descobriu que table é travessia elevada, foi alguma fonte oficial? Mais adiante, pode ser necessário saber. Hum, eu não lembro como vi pela primeira vez, mas pesquisei por imagens usando esse termo, e apareceu placas com esse nome. Pesquisando no DENATRAN, apareceu um outro termo: Faixa Elevada para travessia de pedestres [1]http://www.denatran.gov.br/download/Minuta%20Faixa%20Elevada%2006-05-1.DOC. Eu ainda acho que table pode existir em lugares que não são travessias. Mas se a definição desse termo oficialmente (dada por algum Detran ou pelo DNIT ou pelo CTB) permitir essa interpretação, então traduziremos assim. É, parece que segundo a lei, travessias elevadas tem que ter faixa de pedestre (veja o Art.7°. IV aqui[1]http://www.denatran.gov.br/download/Minuta%20Faixa%20Elevada%2006-05-1.DOC ). Mas me ajudem aqui: o que é minuta, e por que ela não tem um número nela? Quando à questão das depressões, não lembro de ter visto uma antes, então não vou poder ajudar nisso. Em 27 de fevereiro de 2014 12:52, Fernando Trebien fernando.treb...@gmail.com escreveu: Sugestão: ao colocar as traduções, coloque também a fonte delas. Por exemplo, onde você descobriu que table é travessia elevada, foi alguma fonte oficial? Mais adiante, pode ser necessário saber. Eu ainda acho que table pode existir em lugares que não são travessias. Mas se a definição desse termo oficialmente (dada por algum Detran ou pelo DNIT ou pelo CTB) permitir essa interpretação, então traduziremos assim. 2014-02-27 12:28 GMT-03:00 John Packer john.pack...@gmail.com: Amigos, Descobri qual é o termo brasileiro para traffic_calming=table. É Travessia Elevada. Com isso, acredito que os nós da proposta fecham. Farei uma página de desambiguação na wiki chamada Lombada, e redirecionar os links traffic_calming=bump, traffic_calming=hump e traffic_calming=table para essa página. Também adicionarei os seguintes termos na página de referência de traduções: - *Bump* = Lombada Tipo I - *Hump* = Lombada Tipo II - *Table (traffic calming)* = Travessia Elevada E classificarei essas traduções como literais. (isso tudo assim que tiver tempo) Em 27 de fevereiro de 2014 11:28, Fernando Trebien fernando.treb...@gmail.com escreveu: Elas ocorrem em travessias de pedestre, mas pelo que diz na Wikipédia, não só nessa situação. http://en.wikipedia.org/wiki/Vertical_deflection_traffic_calming_device#Speed_tables Talvez no Brasil seja só nessa situação. Além disso, acho que tables não são chamadas de lombadas no Brasil. 2014-02-27 11:23 GMT-03:00 Arlindo Pereira openstreet...@arlindopereira.com: (Acabei mandando antes) Portanto, table seria esse tipo de travessia específica e bump e hump quebra-molas/lombadas, sendo bump o quebra-mola tradicional e hump um tipo de quebra-mola que só seria utilizado em estradas federais ou estaduais. Não há tag para quebra-molas irregulares/ilegais/menores que o tamanho padrão. Podemos propor uma. Mas não acho legal subverter o significado de bump para isso. Talvez dangerous_bump ou bump + irregular=yes ou illegal=yes ou algo do tipo. []s Arlindo 2014-02-27 11:21 GMT-03:00 Arlindo Pereira openstreet...@arlindopereira.com: Não sei. Acho que table é outra coisa. (Importante mencionar que eu não dirijo, ok? Minha impressão é meramente pela observação das ruas.) Pra mim, table é isso: http://www.ite.org/css/online/img/Figure9-17.jpg http://www.cyclestreets.net/location/47587/cyclestreets47587-size640.jpg http://wiki.coe.neu.edu/groups/nl2011transpo/wiki/5e21c/images/__thumbs__/3ffdd.jpg http://2.bp.blogspot.com/-gIoeIhSgaP0/UZu8XGmSnHI/AeU/-c2c-BT2BPs/s1600/Elwick+Road,+Ashford.jpg http://2.bp.blogspot.com/_nqmNLgL2k80/TOV5_AuWSNI/Bao/ptlW4H6I62w/s1600/12457.jpg http://3.bp.blogspot.com/-eZhsiJXAbQA/TdhHhRQKSgI/Aps/DbPwZtSzspw/s1600/San+Telmo+-+Chile.jpg Em resumo, via de regra utilizados em travessias de pedestres aonde não há uma rampa da calçada para o nível do asfalto, mas sim o inverso, uma rampa do asfalto para o nível da calçada. []s Arlindo 2014-02-27 11:14 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Acho que a principal diferença entre table e hump é o formato: hump é suave, table é trapezoidal. Independente da extensão. A Wikipédia diz que humps podem ter entre 3m e 4.3m de extensão. 2014-02-26 23:45 GMT-03:00 John Packer john.pack...@gmail.com: Olha, vendo essa etiqueta traffic_calming=table, eu vou segurar a minha proposta por um bom tempo até conseguir investigar melhor essa situação. A pergunta é: existe alguma lombada de 3+ metros que não seja um traffic_calming=table? (ou seja, que não tenha o topo achatado). Sinceramente, nunca vi, e olha que já vi uns 4-5 traffic_calming=table aqui na minha cidade. Estou pensando que traffic_calming=bump é menor que 1,5m, mas vou
Re: [Talk-br] Proposta de padronização de lombadas no Brasil
Srs, Que tal usar a filosofia KISS aqui e manter somente um tipo de lombada ? Sem diferenciar pelo tamanho, comprimento, material, afinal para que serviria a informação que uma lombada tem 50 cm e não 2 m ? Para mim elas servem para um só fim e o uso de mais de uma tag para identificar elementos virtualmente iguais só aumenta a complexidade ( já considerável ) de se mapear para o OSM. Vejam que no caso de algumas delas terem atreladas faixas de pedestres seriam sim necessárias tags específicas, mas só pq isso muda a função da bendita. Mudando de assunto. Além dos tipos de lombada que vem sendo discutidas, existem locais nas estradas em que são colocados sonorizadores ( exemplo http://goo.gl/uYt6Eu) imediatamente antes das lombadas de forma a avisar aos que não leem placas para diminuir a velocidade. Nestes casos, seria uma tag a mais na lombada ou um elemento adicional ? Não lembro se já vi, in loco, esse tipo de sonorizador sendo usado em outra função que não o aviso de lombada. Att, Marcelo Pereira Em 27 de fevereiro de 2014 13:47, John Packer john.pack...@gmail.comescreveu: Sugestão: ao colocar as traduções, coloque também a fonte delas. Por exemplo, onde você descobriu que table é travessia elevada, foi alguma fonte oficial? Mais adiante, pode ser necessário saber. Hum, eu não lembro como vi pela primeira vez, mas pesquisei por imagens usando esse termo, e apareceu placas com esse nome. Pesquisando no DENATRAN, apareceu um outro termo: Faixa Elevada para travessia de pedestres [1]http://www.denatran.gov.br/download/Minuta%20Faixa%20Elevada%2006-05-1.DOC. Eu ainda acho que table pode existir em lugares que não são travessias. Mas se a definição desse termo oficialmente (dada por algum Detran ou pelo DNIT ou pelo CTB) permitir essa interpretação, então traduziremos assim. É, parece que segundo a lei, travessias elevadas tem que ter faixa de pedestre (veja o Art.7°. IV aqui[1]http://www.denatran.gov.br/download/Minuta%20Faixa%20Elevada%2006-05-1.DOC ). Mas me ajudem aqui: o que é minuta, e por que ela não tem um número nela? Quando à questão das depressões, não lembro de ter visto uma antes, então não vou poder ajudar nisso. Em 27 de fevereiro de 2014 12:52, Fernando Trebien fernando.treb...@gmail.com escreveu: Sugestão: ao colocar as traduções, coloque também a fonte delas. Por exemplo, onde você descobriu que table é travessia elevada, foi alguma fonte oficial? Mais adiante, pode ser necessário saber. Eu ainda acho que table pode existir em lugares que não são travessias. Mas se a definição desse termo oficialmente (dada por algum Detran ou pelo DNIT ou pelo CTB) permitir essa interpretação, então traduziremos assim. 2014-02-27 12:28 GMT-03:00 John Packer john.pack...@gmail.com: Amigos, Descobri qual é o termo brasileiro para traffic_calming=table. É Travessia Elevada. Com isso, acredito que os nós da proposta fecham. Farei uma página de desambiguação na wiki chamada Lombada, e redirecionar os links traffic_calming=bump, traffic_calming=hump e traffic_calming=table para essa página. Também adicionarei os seguintes termos na página de referência de traduções: - *Bump* = Lombada Tipo I - *Hump* = Lombada Tipo II - *Table (traffic calming)* = Travessia Elevada E classificarei essas traduções como literais. (isso tudo assim que tiver tempo) Em 27 de fevereiro de 2014 11:28, Fernando Trebien fernando.treb...@gmail.com escreveu: Elas ocorrem em travessias de pedestre, mas pelo que diz na Wikipédia, não só nessa situação. http://en.wikipedia.org/wiki/Vertical_deflection_traffic_calming_device#Speed_tables Talvez no Brasil seja só nessa situação. Além disso, acho que tables não são chamadas de lombadas no Brasil. 2014-02-27 11:23 GMT-03:00 Arlindo Pereira openstreet...@arlindopereira.com: (Acabei mandando antes) Portanto, table seria esse tipo de travessia específica e bump e hump quebra-molas/lombadas, sendo bump o quebra-mola tradicional e hump um tipo de quebra-mola que só seria utilizado em estradas federais ou estaduais. Não há tag para quebra-molas irregulares/ilegais/menores que o tamanho padrão. Podemos propor uma. Mas não acho legal subverter o significado de bump para isso. Talvez dangerous_bump ou bump + irregular=yes ou illegal=yes ou algo do tipo. []s Arlindo 2014-02-27 11:21 GMT-03:00 Arlindo Pereira openstreet...@arlindopereira.com: Não sei. Acho que table é outra coisa. (Importante mencionar que eu não dirijo, ok? Minha impressão é meramente pela observação das ruas.) Pra mim, table é isso: http://www.ite.org/css/online/img/Figure9-17.jpg http://www.cyclestreets.net/location/47587/cyclestreets47587-size640.jpg http://wiki.coe.neu.edu/groups/nl2011transpo/wiki/5e21c/images/__thumbs__/3ffdd.jpg http://2.bp.blogspot.com/-gIoeIhSgaP0/UZu8XGmSnHI/AeU/-c2c-BT2BPs/s1600/Elwick+Road,+Ashford.jpg
Re: [Talk-br] Proposta de padronização de lombadas no Brasil
Embora eu prefira o método KISS também, se ficar definido como consta no e-mail abaixo até que não fica muito complicado não. Porém, ao invés de somente considerar os 2m, que quase ninguém normal irá medir :), seria bom utilizar a definição prática, pelo menos como sugestão (acho que do Fernando), de se observar se os dois eixos do carro são elevados pela lombada simultaneamente ou não. Se somente um eixo passar pela lombada de cada vez é bump, se forem os dois eixos, hump. Obs.: somente a título de informação, no Tracksource, não há diferenciação de lombadas pelas suas características físicas. Porém, lombadas localizadas em rodovias, nas quais se espera que os veículos estejam trafegando a velocidades maiores ao depararem-se com elas, recebem uma tag diferente das lombadas localizadas em áreas urbanas, com o intuito de permitir a geração de avisos, com o POI Loader ou outro programa similar, com antecedência maior no caso de lombadas de rodovias (200m) do que das urbanas (50m), para que haja tempo suficiente de o veículo reduzir a velocidade. Atenciosamente,Raffaello Bruno From: john.pack...@gmail.com Date: Thu, 27 Feb 2014 14:39:08 -0300 To: talk-br@openstreetmap.org Subject: Re: [Talk-br] Proposta de padronização de lombadas no Brasil Marcelo, Concordo que seria melhor ter só um tipo de lombada, mas já existem essas 3 formas diferentes de etiquetar lombadas no OSM, então é bom ter uma padronização de como os brasileiros utilizam essas etiquetas. Felizmente no final das contas não fica muito complicado não. Basicamente as regrinhas são as seguintes: Se a lombada tiver menos de 2 metros, é traffic_calming=bump Se a lombada tiver mais de 2 metros e não tiver uma faixa de pedestres em cima (e/ou não tiver um topo reto), é traffic_calming=hump Se a lombada tiver mais de 2 metros, uma faixa de pedestres em cima e/ou topo reto, é traffic_calming=table (e highway=crossing se necessário) Adicione highway=speed_camera se for uma lombada eletrônica. Ainda por cima, vale notar que a segunda opção(hump) não é muito comum. A diferença que o tipo de lombada faz é quanto a velocidade em que um carro pode passar por ela, em uma de tipo I (bump), tem que passar mais devagar que nas outras. Quanto aos sonorizadores, eles também são utilizados em algumas rodovias (pra alertar sobre uma curva perigosa, por exemplo) e já tem uma etiqueta própria: traffic_calming=rumble_strip. (rumble strip pode ser traduzido grosseiramente como faixa de barulho) Abs, João ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Parque aquático não renderizado no slippy map do OSM
Pra mim, se eu ir na camada humanitária, aparece o nome. Senão não aparece nada. Gerald, parece que o conjunto de alterações dele foi feito 21 horas atrás. Em 27 de fevereiro de 2014 18:59, Gerald Weber gwebe...@gmail.comescreveu: Para mim aparece. Há quanto tempo você colocou? Pode ser um problema do cache do seu navegador. abraço Gerald 2014-02-27 18:54 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Pessoal, Recentemente coloquei um parque aquático aqui: http://www.openstreetmap.org/#map=17/-22.98126/-43.48673 , mas o mesmo não está sendo renderizado. Pesquisei onde reportar o problema, mas aparentemente não existe onde reportar: http://wiki.openstreetmap.org/wiki/Talk:Slippy_Map#Contcact.2C_error_.2B_wishlist_reporting.3F. Parece algum problema da folha de estilo e não do Mapnik. O parque deveria aparece ao sul do estacionamento e à direita do caminho acesso Rio Water Planet []s PC ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Parque aquático não renderizado no slippy map do OSM
Eu coloquei o estacionamento, o clube, o acesso (esses três aparecem) e o parque no mesmo changeset. Se fosse problema de cache nenhum deles deveria aparecer. Em 27 de fevereiro de 2014 18:59, Gerald Weber gwebe...@gmail.comescreveu: Para mim aparece. Há quanto tempo você colocou? Pode ser um problema do cache do seu navegador. abraço Gerald 2014-02-27 18:54 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Pessoal, Recentemente coloquei um parque aquático aqui: http://www.openstreetmap.org/#map=17/-22.98126/-43.48673 , mas o mesmo não está sendo renderizado. Pesquisei onde reportar o problema, mas aparentemente não existe onde reportar: http://wiki.openstreetmap.org/wiki/Talk:Slippy_Map#Contcact.2C_error_.2B_wishlist_reporting.3F. Parece algum problema da folha de estilo e não do Mapnik. O parque deveria aparece ao sul do estacionamento e à direita do caminho acesso Rio Water Planet []s PC ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Nós isolados sem tags
2014-02-27 19:07 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Como selecionar nós soltos e sem tags no JOSM? Tentei usar os filtors, mas não consegui uma forma de separar os nós sem tags que pertencem a linhas (esses devem ficar, evidentemente) daqueles que estão soltos (esses quero eliminar). O validador do JOSM avisa sobre isso. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Nós isolados sem tags
Encontrei aqui como selecionar: https://help.openstreetmap.org/questions/18424/josm-search-function-find-orphan-nodes A resposta é type:node untagged -child Em 27 de fevereiro de 2014 19:07, Paulo Carvalho paulo.r.m.carva...@gmail.com escreveu: Pessoal, Como selecionar nós soltos e sem tags no JOSM? Tentei usar os filtors, mas não consegui uma forma de separar os nós sem tags que pertencem a linhas (esses devem ficar, evidentemente) daqueles que estão soltos (esses quero eliminar). []s Paulo ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Nós isolados sem tags
Foi a primeira coisa que tentei: Enviar para o validador pegar. Não pegou. Em 27 de fevereiro de 2014 19:14, Nelson A. de Oliveira nao...@gmail.comescreveu: 2014-02-27 19:07 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Como selecionar nós soltos e sem tags no JOSM? Tentei usar os filtors, mas não consegui uma forma de separar os nós sem tags que pertencem a linhas (esses devem ficar, evidentemente) daqueles que estão soltos (esses quero eliminar). O validador do JOSM avisa sobre isso. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Parque aquático não renderizado no slippy map do OSM
A folha de estilo padrão do site (que usa um estilo Mapcss carregado pelo TileMill, que usa o Mapnik por baixo dos panos) e o OSM-Carto: https://github.com/gravitystorm/openstreetmap-carto/ Enquanto não atenderem o seu ticket, acho que você pode atribuir uma tag landuse=recreation_ground (além das tags que já tem). Acho que você sugerir uma renderização igual a park ou a recreation ground. Alguns outros valores de leisure (como leisure=dog_park e leisure=firepit) também não são renderizados e talvez deveriam ser. http://wiki.openstreetmap.org/wiki/Key:leisure 2014-02-27 19:09 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Eu coloquei o estacionamento, o clube, o acesso (esses três aparecem) e o parque no mesmo changeset. Se fosse problema de cache nenhum deles deveria aparecer. Em 27 de fevereiro de 2014 18:59, Gerald Weber gwebe...@gmail.com escreveu: Para mim aparece. Há quanto tempo você colocou? Pode ser um problema do cache do seu navegador. abraço Gerald 2014-02-27 18:54 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Pessoal, Recentemente coloquei um parque aquático aqui: http://www.openstreetmap.org/#map=17/-22.98126/-43.48673 , mas o mesmo não está sendo renderizado. Pesquisei onde reportar o problema, mas aparentemente não existe onde reportar: http://wiki.openstreetmap.org/wiki/Talk:Slippy_Map#Contcact.2C_error_.2B_wishlist_reporting.3F . Parece algum problema da folha de estilo e não do Mapnik. O parque deveria aparece ao sul do estacionamento e à direita do caminho acesso Rio Water Planet []s PC ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Nós isolados sem tags
Perfeito! Obrigado. Em 27 de fevereiro de 2014 19:18, John Packer john.pack...@gmail.comescreveu: Encontrei aqui como selecionar: https://help.openstreetmap.org/questions/18424/josm-search-function-find-orphan-nodes A resposta é type:node untagged -child Em 27 de fevereiro de 2014 19:07, Paulo Carvalho paulo.r.m.carva...@gmail.com escreveu: Pessoal, Como selecionar nós soltos e sem tags no JOSM? Tentei usar os filtors, mas não consegui uma forma de separar os nós sem tags que pertencem a linhas (esses devem ficar, evidentemente) daqueles que estão soltos (esses quero eliminar). []s Paulo ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Nós isolados sem tags
Até agora eu pensei que só caberiam expressões regulares. Critérios topológicos não sabia como fazer, até agora. Em 27 de fevereiro de 2014 19:33, Fernando Trebien fernando.treb...@gmail.com escreveu: Só pra esclarecer (pro Paulo e talvez outros que estejam vendo pela primeira vez): type:node untagged -child é uma expressão pra busca no JOSM. 2014-02-27 19:18 GMT-03:00 John Packer john.pack...@gmail.com: Encontrei aqui como selecionar: https://help.openstreetmap.org/questions/18424/josm-search-function-find-orphan-nodes A resposta é type:node untagged -child Em 27 de fevereiro de 2014 19:07, Paulo Carvalho paulo.r.m.carva...@gmail.com escreveu: Pessoal, Como selecionar nós soltos e sem tags no JOSM? Tentei usar os filtors, mas não consegui uma forma de separar os nós sem tags que pertencem a linhas (esses devem ficar, evidentemente) daqueles que estão soltos (esses quero eliminar). []s Paulo ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-de] Update JOSM Mappaint Style Coloured Streets 2.0
Hallo, Ich wohne in Belgien, wir haben Germanischen sowohl als Romanischen Namen. Ich arbeite schon länger mit diesem Stil und für franzoschinen Namen hilft er nicht wirklich. Deine Lösung mit regex wird in Asien aber auch nicht funktionieren. Leider ist es nicht möglich das Unicode code point zu bekommen, sonst wäre sowas möglich: fill-color: eval(rgb(abs(cos(substring(tag(name),0.0)*36)), abs(sin(substring(tag(name),length(tag(name))/2.0)*36)), abs(cos(substring(tag(name),length(tag(name)))*36; jedes Farbkanal hängt dann ab von die erste Buchstabe, die mittlere un die letzt Buchstabe. Jo 2014-02-27 7:30 GMT+01:00 Christoph thefive@gmail.com: Ich arbeite auch gerne mit dem Stil in leichter Modifikation für die NRW ALK Rasterdarstellung. http://forum.openstreetmap.org/viewtopic.php?id=23576 Christoph Sent from my iDingens Am 27.02.2014 um 00:04 schrieb Gertrud Simson simson.gert...@gmail.com : Am 26. Februar 2014 22:16 schrieb Martin Vonwald imagic@gmail.com: Warum alternative Version und nicht konfigurierbar? Seit einigen Wochen kann man Stil-Farben konfigurierbar machen in JOSM. Das verwende ich im Fahrspur-Stil um verschiedenste Einstellungen konfigurierbar zu machen. Ist zwar nicht hübsch funktioniert aber: bei Optionen bedeutet Weiß - Ja und Schwarz - Nein. Das ist sicher eine Möglichkeit, hatte ich bisher noch nicht bedacht. Die Frage ist nur, ob diese Einstellungen dort dann auch von jedem gefunden und genutzt werden. Aber ich werde mir das mal durch den Kopf gehen lassen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Keine Namen in Mapnik und anderen Karten
Hallo Bernd, entschuldige bitte - das war tatsächlich Bernhard - Schande über mein Haupt; In der Thread-Ansicht war das so weit nach rechts gerutscht, dass ich nur noch auf das Bern| geachtet habe. :/ Gruß Peter Am 26.02.2014 16:01, schrieb Bernd Wurst: Ich mach ja kein Tofu normalerweise aber hier kann ich nicht Sachbezogen antworten: Du legst mir in den Mund, dass ich irgendwas über irgend einen Goetheplatz geschrieben hätte. Habe ich nie. Ich weiß nichts von einem Goetheplatz. Lass das bitte. Am 26.02.2014 11:57, schrieb Peter Wendorff: Am 26.02.2014 11:20, schrieb Bernd Wurst: Hallo Peter. Zunächst: Watch your tone. Ehrlich. Am 26.02.2014 11:00, schrieb Peter Wendorff: Hallo Bernd, was hältst Du davon, konkrete Probleme zu verlinken, damit man konkrete Fragen stellen kann, was da was ist oder sein soll. Dass ein Name am Goetheplatz fehlt, hattest du geschrieben. Nein, habe ich nicht geschrieben. Stimmt, du hattest nur gefragt (Mail von gestern, 25.2., 23:12): Wie trägt man zukünftig den Goetheplatz ein, damit der Name des allseits bekannten Platzes auf der Karte erscheint? Ich nehme an, der Name von area = yes wird dann nicht mehr angezeigt. Vielleicht hab ich da also einen konkreten Fehlerfall reininterpretiert, den es nicht einmal gab oder gibt - dann entschuldige ich mich für den Ton (erlaube mir aber, die Frage zu stellen, was du damit eigentlich erfragen wolltest). Dass das zusammen mit highway=pedestrian und area=yes korrekt gerendert werden sollte, hast du hier auch schon lesen können. Ja, betrifft mich aber null komma gar nicht. Sondern? Was betrifft dich denn dann? Denn die Frage hast du ja schon gestellt, zumindest ist die Mail bei mir so eingegangen. Was genau du brauchst, hast du ja nicht geschrieben - ich weiß nur, dass es um irgendeinen der Goetheplätze geht, die es gibt. Wer aber sollte jetzt ein Ticket aufgrund einer Fehlermeldung aufmachen, die nur auf Hörensagen beruht, weil niemand außer dir das direkt überprüfen kann (denn Goetheplatz gibt's schon ganz schön häufig). Ich habe nur von einigen Waldwegen gesprochen. Eigentlich sind es alle Waldwege. Ich kann dir hunderte Links schicken. Oder du schaust einfach irgend einen x-beliebigen Waldweg an. Das Waldweg-Thema ist ein anderes und doch geklärt - da fehlt noch die Render-Regel, die beim Catch-All weggefallen ist, da kann man gucken, ob es ein Ticket gibt und bei Bedarf eins erstellen, einen Patch einreichen etc., darauf habe ich mich aber nicht bezogen. Also: Gib uns einen Link und es wird jemand versuchen, dir zu helfen - jedenfalls ist das meistens der Fall. Soviel also zu deiner Frage was denn noch. Die Frage war ganz konkret: Was ist bei einem normalen Weg denn außer name noch nötig um ein Redering des Namens zu erwirken. Dass es *kein* area-Tag geben soll konnte man hier heraus lesen. Aber meine Wege haben kein area-Tag. das area-Tag ist nicht ausschlaggebend fürs Rendering; es ist aber notwendig, um ein lineares feature als Fläche darzustellen. waldwege: Da fehlt die Rendering-Regel, Goetheplatz: da fehlt das Wissen darüber, was da überhaupt drangetagged ist - und das verweigerst du ja weiterhin (oder es interessiert dich tatsächlich nicht mehr). Meine Mutmaßung ist ja, dass hier der Style von highway=* auf einige wenige explizit eingetragene Werte eingeschränkt wurde. Das kann man machen, muss dann aber auch alle etablierten Werte berücksichtigen. Bisher scheint track kein gültiger Wegtyp in diesem Sinne zu sein. Ich seh's irgendwie nicht ein, für ein Problem einen Bugreport [1] auf zu machen das derart offensichtlich ist. Wer das verbockt hat, soll sich bitte auch darum kümmern dass das gefixed wird. Ich glaube, bei konkreten Fehlermeldungen (wie gesagt: ich red vom Goetheplatz) würde das jemand übernehmen; spätestens auf eine direkte Bitte hin. Aber aus wagen Aussagen ein Ticket zu bauen ist etwas mehr Arbeit als sich bei github anzumelden. Wer das verbockt hat hat im Zuge dessen etliche andere Fehler behoben und damit die Gesamtlage im Rendering eher verbessert; zumindest aber langfristig eine richtige Grundlage gelegt, um gezielt eine korrekte Darstellung genau da zu erzielen, wo sie gewünscht wird. Wenn Du mit github ein Problem hast, frag doch einfach freundlich nach, beschreibe das Problem konkret und so, wie du es auch in ein Ticket schreiben würdest, und bitte darum, dass daraus jemand ein Ticket macht, ich bin sicher, dass dir das nicht verwehrt wird. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update JOSM Mappaint Style Coloured Streets 2.0
+1 insbesondere würde das auch Tippfehler in Straßennamen einzelner Adressen visualisieren. Gruß Peter Am 26.02.2014 22:50, schrieb Florian Lohoff: On Wed, Feb 26, 2014 at 09:38:39PM +0100, Gertrud Simson wrote: Außerdem gibt es jetzt eine alternative Version, in der statt des ersten der letzte Buchstabe des Straßennamens ausgewertet wird. Dies ist geeignet für Länder, wo viele Straßen mit dem gleichen Buchstaben beginnen (z.B. in Frankreich Rue ...). Ich würde ein MD5 oder aehnlichen Hash verwenden über den Straßennamen und darauf das meinswegen erste Zeichen. Damit ist es egal an welcher stelle des strings eine veränderung eintritt. Flo ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Access-Tags
Am 27.02.2014 07:58, schrieb Manuel Reimer: Also eigentlich ein access = yes um alles zu erschlagen. Im Wiki wird von der Kombination access = yes aber abgeraten. Wie ist es also richtig und vollständig wenn man einen Waldweg mit oben genannten Schildern taggen will ohne unnötig viel Tag-Wirrwarr zu produzieren? Gilt bei Access-Tags alles was nicht verboten ist, ist erlaubt oder muss alles was erlaubt ist dran stehen? Wenn letzteres: Muss dann auch an jedem highway = residential die ganze Access-Tag-Flut dranstehen und wenn nein: Warum nicht? Moin, es gibt im Wiki eine Tabelle[1] mit den default-access-rights pro Wegklasse. Das Setzen expliziter Tags ist also nur bei abweichenden Beschränkungen notwendig. Das OSM Verkehrszeichentool unterstützt bei der Findung der korrekten Tags: http://osmtools.de/traffic_signs/?signs=260,1026-37 Chris [1] http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Access-Tags
Hallo Christian, ich gebe dir nur zum Teil recht; die Tabelle war mir im Übrigen neu. Zunächst eine Frage: Welche Anwendung hält sich an diese Tabelle? Und gleich darauf aufbauend: gibt es eine maschinenlesbare Version, oder muss jede Anwendung jede mögliche Änderung der Tabelle wieder manuell einbauen? Eine solche Tabelle ist wertlos, wenn Routing-Software sie nicht einsetzt. Offensichtlich gibt es aber irgendein Projekt, dass sie einsetzt, aber nicht auf der Seite genannt wird - die Formulierung designated - same as yes but this road can optionally be prefered by some of your metrics. deutet jedenfalls darauf hin. Abgesehen davon ist ein Kernproblem der default-Frage nicht geklärt: Wie erkenne ich als Mapper (!), ob ich bei einer bestimmten Straße nochmal nachgucken sollte, was gilt, oder ob die default-Werte gelten? Dass Routingsoftware die Default-Werte annimmt ist ja schön und gut - aber wie unterscheidet man zwischen default und fehlend? Das ist nämlich leider nicht möglich. Für die Routingsoftware ist das egal - die muss mit fehlenden Daten irgendwie halbwegs sinnvoll umgehen können und entsprechend defaults annehmen; aber besser wäre es, wenn die Route nicht auf Annahmen, sondern auf vorhandene Daten gestützt werden könnte. Blöderweise gibt es aber eben mehrere verschiedene default-Semantiken: 1) Was nimmt Routingsoftware X an, wenn keine Angabe in den Daten steht? Diese Frage lässt sich mit einer solchen Tabelle dokumentieren und beantworten; notwendig dafür wäre aber auch die Angabe der Router, die sich danach richten, denn natürlich ist es keine völlig unsinnige Entscheidung, highway=track nur im Notfall in die Auto-Route mit einzubeziehen, womit es meist access=destination entsprechen dürfte. 2) Was ist ohne besondere Ausschilderung gültig? Bezieht sich neben den access-Tags insbesondere auch auf Geschwindigkeitsbegrenzungen, hat aber mit OSM und dem Mapping eigentlich wenig zu tun, sondern entspricht weitgehend (1) für Software, die sich an die Regeln hält. Was ausgeschildert dransteht würde ich aber immer auch so eintragen. Wenn an einer Straße innerorts (in DE) ein Tempo-50-Schild dransteht, dann trage ich das so auch ein - obwohl innerorts per default 50 gilt. Denn falls irgendwann die Geschwindigkeit generell auf 30 gesenkt werden sollte, gelten bestehende Schilder mit 50 weiterhin. Es ändern sich also die Regeln genau für die Fälle, wo dies nicht dransteht. Aus den Gründen finde ich die Tabelle einen guten Ansatz - aber nur, wenn die Erklärung dazu passt, und die fehlt bisher. Wer großflächig an Bundes- und Landstraßen maxspeed=100 tagged, nur weil kein Schild dransteht, erzeugt Probleme für mögliche Anpassungen der Höchstgeschwindigkeit, z.B. auf 70, was jetzt schon auf einem großteil der Landstraßen gilt. Gruß Peter Am 27.02.2014 11:22, schrieb chris66: Am 27.02.2014 07:58, schrieb Manuel Reimer: Also eigentlich ein access = yes um alles zu erschlagen. Im Wiki wird von der Kombination access = yes aber abgeraten. Wie ist es also richtig und vollständig wenn man einen Waldweg mit oben genannten Schildern taggen will ohne unnötig viel Tag-Wirrwarr zu produzieren? Gilt bei Access-Tags alles was nicht verboten ist, ist erlaubt oder muss alles was erlaubt ist dran stehen? Wenn letzteres: Muss dann auch an jedem highway = residential die ganze Access-Tag-Flut dranstehen und wenn nein: Warum nicht? Moin, es gibt im Wiki eine Tabelle[1] mit den default-access-rights pro Wegklasse. Das Setzen expliziter Tags ist also nur bei abweichenden Beschränkungen notwendig. Das OSM Verkehrszeichentool unterstützt bei der Findung der korrekten Tags: http://osmtools.de/traffic_signs/?signs=260,1026-37 Chris [1] http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Access-Tags (was: Re: Keine Namen in Mapnik und anderen Karten)
Am 27.02.14 schrieb Manuel Reimer: Im Wiki gibt es zwar gute Beispiele mit Tagging das mir auch logisch erscheint aber kein Wort darüber, dass man für alles, was erlaubt ist, ein Access-Tag setzen muss. Ich gehe davon aus, dass der Default gilt http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions und trage davon abweichendes ein (und gehe davon aus, dass sich Länder ohne track-Zeile auf den globalen Durchschnitt einigen). Gruß, Fabian.___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Access-Tags (was: Re: Keine Namen in Mapnik und anderen Karten)
Am 27. Februar 2014 07:58 schrieb Manuel Reimer manuel.s...@nurfuerspam.de: Mir geht es um dieses Schild: http://commons.wikimedia.org/wiki/File:Zeichen_260.svg Mit dem Zusatz darunter Land- und forstwirtschaftlicher Verkehr frei. Ich lese da erstmal das motorisierte Fahrzeuge verboten sind. Weiterhin lese ich eine Einschränkung, die forst/landwirschaftlichen Verkehr freigibt. Also motor_vehicle = agricultural. Ich sehe auf dem Schild keinerlei Einschränkungen bezüglich Fußgängern oder Radfahrern. Mit dem von dir vorgenommenen Tagging bist du unserer on the ground rule vollkommen gerecht geworden. Das Problem liegt auf der Auswertungsseite. Eine Auswertungsmaschine erkennt anhand deines taggings nicht, dass dort StVO-Verkehrszeichen Nr. 260 stand. Die StVO geht implizit davon aus, dass man auf Straßen erst einmal mit allen Fahrzeugen (und zu Fuß) lang darf. Wenn das für bestimmte Fortbewegungsarten nicht gilt, wird das durch Schild gesagt. Die Maschine muss also nicht nur forst- und landwirtschaftlicher Verkehr frei (motor_vehicle=agricultural) denken, sondern gleichzeitig auch noch alle anderen Motorfahrzeuge nicht. Eine Aussage zu Fahrrädern und Fußgängern ist in der Aussage nicht enthalten. Die StVO sagt die dürfen bei Schild Nr. 260 durch. Das muss die Maschine auch denken. Warum sie das denkt ist der alte streit zwischen default-Annahmen und expliziten Tagging. Anders ist das schon wieder, wenn man sich im Geltungsbereich eines Landeswaldgesetzes befindet. Nehmen wir zum Beispiel § 37 Abs. 3 LWaldG B-W: [...] das Radfahren und [...] sind nur auf Straßen und hierfür geeigneten Wegen gestattet. [...] Nicht gestattet sind [...] das Radfahren auf Wegen unter 2 m Breite sowie [...] Radfahren auf Sport- und Lehrpfaden; die Forstbehörde kann Ausnahmen zulassen. [...] Hier ergibt sich die erlaubte Benutzung nicht aus der StVO und deren Grundannahmen gelten hier nicht. Es gilt das Landeswaldgesetz, dafür reicht ein Hinweis am Anfang des Weges. Hier ergibt sich der Zugang für Radfahrer daraus ob es sich um eine (Wald-)straße oder einen mindestens zwei Meter breiten (Wald-)Weg handelt. Außerdem kann die Forstbehörde eine ausdrückliche Erlaubnis (z.B. durch Beschilderung) erteilen. Das alles lässt sich meiner Meinung nach nur durch explizites Tagging vernünftig in die Datenbank übertragen, von Mappern, die sich in ihrem Bundesland mit den Zugangsregeln auskennen. Denn die Zugangsregeln nach den LWaldG variieren von Bundesland zu Bundesland. Die Maschine liest highway=track und muss denken: forst- und landwirtschaftlicher Verkehr frei, alle anderen Motorfahrzeuge nicht; Fußgänger ja; Fahrradfahrer -- in welchem Bundesland bin ich? Ist es eine Straße oder ein Weg? Und wenn es ein Weg ist, wie breit ist der Weg? Da ist doch explizites Tagging die bessere Lösung oder? Kurzum, hier stehen on the ground rule und Maschinenlesbarkeit in einem widerstreitenden Verhältnis, weil man gesetzliche Zugangsregelungen nur zum Teil explizit auf Schildern findet und zu großen Teilen nur im Gesetzestext. Außerdem erleichtert das explizite Tagging die internationale Nutzbarkeit der Daten, weil die Zugangsbeschränkungen ausdrücklich am Weg stehen und niemand überlegen muss, welches Gesetz mit welchen impliziten Annahmen eigentlich gilt. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Access-Tags
Am 27.02.2014 12:59, schrieb Falk Zscheile: Denn die Zugangsregeln nach den LWaldG variieren von Bundesland zu Bundesland. Bewusst provokant: Mit dem Argument kann man aber auch die Defaults für Staaten weglassen - denn auch die variieren von Staat zu Staat. Oder andersrum: So wie es eine Tabelle für Defaults pro Staat gibt, könnte es auch eine verfeinerte Tabelle für weitere Gliederungsebenen geben, in Deutschland eben Bundesländer. Nur sinkt die Wahrscheinlichkeit, dass Anwendungen so etwas in dem Detailgrad unterstützen, natürlich weiter. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Access-Tags (was: Re: Keine Namen in Mapnik und anderen Karten)
Am 27/feb/2014 um 12:56 schrieb Fabian Schmidt fschm...@informatik.uni-leipzig.de: Ich gehe davon aus, dass der Default gilt echte Daten (d.h. vor Ort vom Mapper erhobene und dann eingetragene Informationen) sind besser als ein sich verlassen auf vermeintliche Defaults. Klar, jeder kann eintragen was er will, aber Sachen rauszulöschen, die zwar stimmen aber vom einzelnen Mapper als redundant wg. defaults angesehen werden, ist m.E. dagegen nicht ok Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Access-Tags
Am 27/feb/2014 um 12:17 schrieb Peter Wendorff wendo...@uni-paderborn.de: Wer großflächig an Bundes- und Landstraßen maxspeed=100 tagged, nur weil kein Schild dransteht, erzeugt Probleme für mögliche Anpassungen der Höchstgeschwindigkeit, z.B. auf 70, was jetzt schon auf einem großteil der Landstraßen gilt. ausser man ergänzt z.B. den source maxspeed tag mit DE:rural/sign womit klar wird, ob es ein explizites (ausgeschildertes) Limit oder ein implizites ist. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Access-Tags
Hallo, On Thu, Feb 27, 2014 at 12:17:33PM +0100, Peter Wendorff wrote: Abgesehen davon ist ein Kernproblem der default-Frage nicht geklärt: Wie erkenne ich als Mapper (!), ob ich bei einer bestimmten Straße nochmal nachgucken sollte, was gilt, oder ob die default-Werte gelten? Dass Routingsoftware die Default-Werte annimmt ist ja schön und gut - aber wie unterscheidet man zwischen default und fehlend? Das ist nämlich leider nicht möglich. Richtig. Die Erkennung, ob nicht gesetzte Werte fehlen oder nicht benötigt werden da die Standardwerte ausreichen, ist momentan nicht möglich. Das wird auch immer das Problem von Standardwerten bleiben. Wobei ich damit nicht sagen möchte, dass Standardwerte generell schlecht sind. Denn gerade im Fall von den Zugangsbeschränkungen stimmen die Standardwerte oft mit der Realität überein. Man kann alle zutreffenden Standardwerte natürlich zusätzlich explizit eintragen, dann ist hinterher klar dass diese auch tatsächlich geprüft wurden. Aber Wege grundsätzlich mit zig access-Tags zu versehen ist auch ziemlich unschön. Der Vorteil des Nicht-Eintragens von Standardwerten ist auch der, dass sich diese aufgrund von neuen Gesetzen auch mal ändern können. Diese Änderung wird aber nur dann automatisch übernommen (=sobald die Daten-Konsumenten ihre Programme entsprechend angepasst haben), wenn Standardwerte nicht nochmal explizit gesetzt wurden. Denn ansonsten muss jeder einzelne Weg wieder per Hand aktualisiert und eigentlich auch nochmal vor Ort überprüft werden. Die einzige Lösung, die ich hier sehe, wäre ein zusätzliches Tag. Dieses wird genau dann gesetzt, wenn die Standardwerte gelten, also kein zusätzliches Schild am Weg ist. Das lässt einerseits nachvollziehen, dass die Zugangsbeschränkungen geprüft wurden, und führt andererseits auch zu einer automatischen Aktualisierung, falls sich diese Standardwerte durch eine Gesetzesänderung ändern. Grüße Alex ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Access-Tags
Am 27.02.2014 12:17, schrieb Peter Wendorff: Dass Routingsoftware die Default-Werte annimmt ist ja schön und gut - aber wie unterscheidet man zwischen default und fehlend? Das ist nämlich leider nicht möglich. Für die Routingsoftware ist das egal - die muss mit fehlenden Daten irgendwie halbwegs sinnvoll umgehen können und entsprechend defaults annehmen; aber besser wäre es, wenn die Route nicht auf Annahmen, sondern auf vorhandene Daten gestützt werden könnte. +1 Das ist genau das große Problem. Ein Mapper sollte in meinen Augen die Objekte so gut wie möglich beschreiben. Allerdings nutzt auch ein access=yes an einem Weg nicht viel als Zeichen, dass hier alles ok ist. Ein Tag nach der Datenerfassung kann da ein neues Schild aufgestellt worden sein. ;) Henning ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Access-Tags
Am 27.02.2014 15:12, schrieb Martin Koppenhoefer: Am 27/feb/2014 um 12:56 schrieb Fabian Schmidt fschm...@informatik.uni-leipzig.de: Ich gehe davon aus, dass der Default gilt echte Daten (d.h. vor Ort vom Mapper erhobene und dann eingetragene Informationen) sind besser als ein sich verlassen auf vermeintliche Defaults. Klar, jeder kann eintragen was er will, aber Sachen rauszulöschen, die zwar stimmen aber vom einzelnen Mapper als redundant wg. defaults angesehen werden, ist m.E. dagegen nicht ok Am besten immer davon ausgehen, dass der Kollege sich etwas dabei gedacht hat, die Info so einzutragen. Wenn es nicht wirklich falsch ist, sollte man daran dann auch nichts ändern. Möchte man ja selber auch nicht unbedingt, dass ein anderer Mapper die eigenen Edits nach seinen Vorstellungen anpasst. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Keine Namen in Mapnik und anderen Karten
Hallo Peter und Mitleser, der Goetheplatz ist eine fiktive Annahme. Meine Frage war, wie man so einen Platz jetzt taggen müsste, wenn er aus Fußgängerbereich, Rasenflächen, Büschen, Parkplatz und mehr besteht. Das kann man sich doch einfach vorstellen. In Mannheim gibt es beispielsweise den Friedensplatz https://www.openstreetmap.org/way/163410379 Der ist inzwischen teilweise bebaut, heißt aber immer noch so. Oder in der Mitte von Mannheim liegt der Paradeplatz http://osm.org/go/0DwUI0~0Y--?m= Hier ist die Grünfläche getagged mit name = Paradeplatz (O1). Der Platz ist aber größer als die Grünfläche, aber so wird der Name wenigstens angezeigt. Wie trägt man den Platz richtig ein? Das (O1) gehört übrigens nicht zum Namen des Platzes, sondern O1 ist der Name des Quadrats, die Quadratenamen werden aber auch nicht mehr angezeigt. Ein typisches Straßenschild wird hier gezeigt http://commons.wikimedia.org/wiki/File:MannheimQuadrat-D4-1-6.jpg Dabei könnt ihr auch mal etwas kleiner zoomen und euch überlegen, wie man sich in Mannheim mit der Mapnik-Karte orientieren kann. Die Straßennamen Fressgasse, Kunststraße usw. sind nur vereinzelt bis gar nicht angeschrieben, sind keine Bestandteile der Adressen. Die Adressen lauten zum Beispiel M4, 4 (Quadrat M4, Hausnummer 4) für das Blumengeschäft Feldblume. Oder: In der Vogelstang gibt es den Vogelstangkreisel http://osm.org/go/0DwWQbyPA--?m= Der ist unter diesem Namen bekannt und wird auch in der Presse so bezeichnet. Wie trägt man den ein, dass man ihn auf der Karte und vielleicht auch in Nominatim findet? Auf jeden Fall ist die Qualität der Karte langfristig besser, wenn man sich solche Gedanken explizit macht, statt einfach mal alles, was einen Namen hat, auf die Karte zu bringen. Ich vermute, wer sein Flugbeschränkungsgebiet R123 auf der Karte sehen will, wird einen Weg finden und ein anderes tag dazufügen, dass der Name wieder angezeigt wird. Vielleicht fördern die aktuellen Änderungen sogar das Falschtaggen. Jedenfalls werden jetzt viele wichtige Namen nicht mehr angezeigt. Bernhard -Ursprüngliche Nachricht- Von: Peter Wendorff [mailto:wendo...@uni-paderborn.de] Gesendet: Mittwoch, 26. Februar 2014 11:00 An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Keine Namen in Mapnik und anderen Karten Hallo Bernd, was hältst Du davon, konkrete Probleme zu verlinken, damit man konkrete Fragen stellen kann, was da was ist oder sein soll. Dass ein Name am Goetheplatz fehlt, hattest du geschrieben. Dass das zusammen mit highway=pedestrian und area=yes korrekt gerendert werden sollte, hast du hier auch schon lesen können. Wenn das nicht korrekt dargestellt wird, ist das meines Erachtens ein Fehler im aktuellen Rendering - dann muss man eine entsprechende Fehlermeldung machen; auch dazu wäre ein konkreter Verweis auf eine Stelle in der Karte sinnvoll. Wer aber sollte jetzt ein Ticket aufgrund einer Fehlermeldung aufmachen, die nur auf Hörensagen beruht, weil niemand außer dir das direkt überprüfen kann (denn Goetheplatz gibt's schon ganz schön häufig). Also: Gib uns einen Link und es wird jemand versuchen, dir zu helfen - jedenfalls ist das meistens der Fall. Soviel also zu deiner Frage was denn noch. Gruß Peter Am 26.02.2014 08:46, schrieb Bernd Wurst: Hallo. Am 26.02.2014 08:31, schrieb Walter Nordmann: Bernhard Weiskopf wrote Wie trägt man das jetzt ein? Genügt name = ... nicht mehr? Ja, name=* reicht nicht mehr aus - und das ist gut so! Ja, aber selbst highway=... und name=... reicht scheinbar nicht aus? Was denn noch? render_this_name=yes oder wie? :-) ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Access-Tags
Am 27.02.2014 08:16, schrieb Bernd Wurst: muss ein Waldweg in Ba-Wü mind. 3 Meter breit und befestigt sein, damit man darauf reiten darf. BTW: ich kenne einen Waldweg (in der Region Stuttgart) der sicher sein 3 Meter Breite haben dürfte und der explizit mit einem Schild für alles mögliche (explizit auch Fußgänger!) gesperrt ist. Also irgendwelche Annahmen Waldweg darf jeder laufen ist nicht korrekt... Grüße, Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Access-Tags
Am 27.02.2014 15:12, schrieb Martin Koppenhoefer: echte Daten (d.h. vor Ort vom Mapper erhobene und dann eingetragene Informationen) sind besser als ein sich verlassen auf vermeintliche Defaults. die Erfahrung habe ich vor einigen (!) Jahren bei OSM auch gemacht. In der Anfangszeit von OSM hatte man die highway=motorway_link nicht explizit mit oneway=yes gekennzeichnet sondern als Default des Typs motorway_link angenommen. Diese Definition wurde irgendwann urplötzlich geändert. Und seit dieser schlechten Erfahrung versuche ich mich nicht mehr auf Default zu verlassen... Grüße, Michael. PS: ich hoffe ich erinnere mich noch korrekt, oder war das motorway selber? ist bestimmt schon 5 Jahre her... ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Access-Tags
Am 27.02.2014 19:28, schrieb Henning Scholland: Am besten immer davon ausgehen, dass der Kollege sich etwas dabei gedacht hat, die Info so einzutragen. Wenn es nicht wirklich falsch ist, sollte man daran dann auch nichts ändern. +10 Grüße, Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Access-Tags
Waldweg darf jeder laufen gilt nur, wenn lokal nichts anderes geregelt ist. Ähnlich einer zweispurigen Landstraße mit Schildern zur Geschwindigkeitsbegrenzung auf 70 km/h, obwohl in der Verkehrsordnung 100 km/h steht. Im Käfertaler Wald in Mannheim sind viele Reitwege schmaler als 3 m. Da sie aber als Reitweg markiert sind, darf man dort trotzdem reiten. Die lokale Beschilderung überschreibt die Default-Regelung. Bernhard -Ursprüngliche Nachricht- Von: Michael Kugelmann [mailto:michaelk_...@gmx.de] Gesendet: Donnerstag, 27. Februar 2014 22:56 An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Access-Tags Am 27.02.2014 08:16, schrieb Bernd Wurst: muss ein Waldweg in Ba-Wü mind. 3 Meter breit und befestigt sein, damit man darauf reiten darf. BTW: ich kenne einen Waldweg (in der Region Stuttgart) der sicher sein 3 Meter Breite haben dürfte und der explizit mit einem Schild für alles mögliche (explizit auch Fußgänger!) gesperrt ist. Also irgendwelche Annahmen Waldweg darf jeder laufen ist nicht korrekt... Grüße, Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Access-Tags
Von: Michael Kugelmann [mailto:michaelk_...@gmx.de] Am 27.02.2014 19:28, schrieb Henning Scholland: Am besten immer davon ausgehen, dass der Kollege sich etwas dabei gedacht hat, die Info so einzutragen. Wenn es nicht wirklich falsch ist, sollte man daran dann auch nichts ändern. +10 Sehe ich genauso. Auch wenn ein Eintrag meiner Meinung nach redundant ist, aber nicht falsch, lasse ich ihn stehen. Außerdem gibt es wichtigere Dinge, als den Mapper anzuschreiben und nach seiner Meinung oder Begründung zu fragen. Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Eintrag von Gewann-Namen
Hallo an alle, wie trägt man in OSM die Namen von Gewannen ein, dass sie in Mapnik angezeigt werden? Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wald aufteilen um Namen anzuzeigen?
Das zusammenhängende Naherholungsgebiet Käfertaler Wald http://osm.org/go/0DwVt4CE-?m= ist untergliedert in vier Teile (Käfertaler Wald, Herrschaftswald, Sandhofer Wald und Neuwald), die bis jetzt mit area = yes eingetragen sind, nun aber nicht mehr angezeigt werden. Außerdem laufen breite Schneisen (Autobahnen) durch, aber nicht an den Grenzen der einzelnen Wälder. Muss man den Käfertaler Wald jetzt aufteilen in viele Wälder und die zusammengehörenden Teile mit Relationen wieder zusammenfügen oder die Autobahnen über Relationen herausnehmen oder gibt es eine einfachere Lösung, dass die Namen der Wälder wieder angezeigt werden? Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eintrag von Gewann-Namen
Die richtige Frage müsste eigentlich lauten: Wie trägt man in OSM Gewannen ein, sodass es den (im Wiki definierten) Regeln entspricht? Ansonsten wäre es Taggen für den Renderer: http://wiki.openstreetmap.org/wiki/DE:Tagging_for_the_renderer VG Am 27. Februar 2014 23:16 schrieb Bernhard Weiskopf bweisk...@gmx.de: Hallo an alle, wie trägt man in OSM die Namen von Gewannen ein, dass sie in Mapnik angezeigt werden? Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eintrag von Gewann-Namen
Hätte ich gerne geschrieben, ich habe aber keine (im Wiki definierten) Regeln gefunden. Gruß Bernhard PS: Ich will für die Benutzer taggen (tagging for users) -Ursprüngliche Nachricht- Von: Gertrud Simson [mailto:simson.gert...@gmail.com] Gesendet: Donnerstag, 27. Februar 2014 23:59 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] Eintrag von Gewann-Namen Die richtige Frage müsste eigentlich lauten: Wie trägt man in OSM Gewannen ein, sodass es den (im Wiki definierten) Regeln entspricht? Ansonsten wäre es Taggen für den Renderer: http://wiki.openstreetmap.org/wiki/DE:Tagging_for_the_renderer VG Am 27. Februar 2014 23:16 schrieb Bernhard Weiskopf bweisk...@gmx.de: Hallo an alle, wie trägt man in OSM die Namen von Gewannen ein, dass sie in Mapnik angezeigt werden? Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eintrag von Gewann-Namen
Dann gibt es wahrscheinlich noch keine Regel. Müsste man sich welche ausdenken und darauf einigen. Hier http://osm.org/go/0GB_460Q- sind Gewannen mit place=locality und name=* eingetragen. Laut http://wiki.openstreetmap.org/wiki/DE:Tag:place%3Dlocality passt das auch ganz gut zu Gewannen, meiner Meinung nach. In diesem Fall wird der Name derzeit von Mapnik auch gerendert. (Das sollte jedoch kein Argument für oder gegen die Auswahl des Taggings sein.) VG ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eintrag von Gewann-Namen
Am 28/feb/2014 um 00:28 schrieb Gertrud Simson simson.gert...@gmail.com: Dann gibt es wahrscheinlich noch keine Regel. Müsste man sich welche ausdenken und darauf einigen. +1 Hier http://osm.org/go/0GB_460Q- sind Gewannen mit place=locality und name=* eingetragen. Laut http://wiki.openstreetmap.org/wiki/DE:Tag:place%3Dlocality passt das auch ganz gut zu Gewannen und nicht nur für die ;-) das ist das Problem an locality, dass es ziemlich unspezifisch ist. Man könnte vielleicht sowas wie locality=field_name verwenden. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Keine Namen in Mapnik und anderen Karten
Hallo, On 27.02.2014 22:47, Bernhard Weiskopf wrote: der Goetheplatz ist eine fiktive Annahme. Meine Frage war, wie man so einen Platz jetzt taggen müsste, wenn er aus Fußgängerbereich, Rasenflächen, Büschen, Parkplatz und mehr besteht. Das kann man sich doch einfach vorstellen. Ja, aber das ist ein altes Problem, das wir auch in anderen Größenordnungen haben. Wie zum Beispiel taggen wir den Alpenraum oder den Odenwald oder die norddeutsche Tiefebene oder den finnischen Meerbusen - all diese Ortsbezeichnungen haben keine exakt definierten Grenzen, und das gilt im Kleinen auch in der Innenstadt - gehört die Grasfläche jetzt noch zum Platz oder nicht, und so weiter. Dabei könnt ihr auch mal etwas kleiner zoomen und euch überlegen, wie man sich in Mannheim mit der Mapnik-Karte orientieren kann. Dass man sich mit der Karte orientieren kann, ist nicht das Haupt-Design-Ziel der Mapnik-Karte. Aber es steht jedem frei, aus den Daten eine Karte zu rendern, die zum Orientieren besser geeignet ist. Oder: In der Vogelstang gibt es den Vogelstangkreisel http://osm.org/go/0DwWQbyPA--?m= Der ist unter diesem Namen bekannt und wird auch in der Presse so bezeichnet. Wie trägt man den ein, dass man ihn auf der Karte und vielleicht auch in Nominatim findet? Es gibt ja loc_name für lokal genutzte Namen, die werden von Nominatim auch gefunden. Auf der Karte erscheinen sie nicht, aber genauso wie man eine gälische Karte machen kann, kann man auch eine machen, die den loc_name, wo vorhanden, bevorzugt. Ich vermute, wer sein Flugbeschränkungsgebiet R123 auf der Karte sehen will, wird einen Weg finden und ein anderes tag dazufügen, dass der Name wieder angezeigt wird. Ja, aber entweder taggt er es korrekt als Flugbeschränkungsgebiet, dann sollen sich die Stil-Maintainer drüber streiten, ob sie es anzeigen wollen oder nicht, oder er taggt es falsch als Naherholungsgebiet oder so, und dann kann man es löschen. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Keine Namen in Mapnik und anderen Karten
Am 28/feb/2014 um 01:02 schrieb Frederik Ramm frede...@remote.org: und das gilt im Kleinen auch in der Innenstadt - gehört die Grasfläche jetzt noch zum Platz oder nicht, und so weiter. und wenn sie dazugehört, wie taggt man das dann? Ich habe bei innerstädtischen Plätzen eigentlich nie oder nur höchst selten ein Problem damit, die Grenzen zu erkennen (zugegebenermaßen allerdings eine Frage des Städtebaus, und in manchem Kontext (zB sozialistisch oder auch modern, autogerecht, funktionsgetrennt und offen) schwieriger als in anderen), einen spezifischen Tag für diese Art Toponym haben wir aber bisher nicht entwickelt abseits von befestigten (Verkehrs-)Flächen, könnte man mal machen. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eintrag von Gewann-Namen
Hallo Bernhard, Schön das Du auch für mich taggst. Nur woher weisst Du das ich Mapnik nutze ? Ein User. Sent from my iDingens Am 28.02.2014 um 00:08 schrieb Bernhard Weiskopf bweisk...@gmx.de: Hätte ich gerne geschrieben, ich habe aber keine (im Wiki definierten) Regeln gefunden. Gruß Bernhard PS: Ich will für die Benutzer taggen (tagging for users) -Ursprüngliche Nachricht- Von: Gertrud Simson [mailto:simson.gert...@gmail.com] Gesendet: Donnerstag, 27. Februar 2014 23:59 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] Eintrag von Gewann-Namen Die richtige Frage müsste eigentlich lauten: Wie trägt man in OSM Gewannen ein, sodass es den (im Wiki definierten) Regeln entspricht? Ansonsten wäre es Taggen für den Renderer: http://wiki.openstreetmap.org/wiki/DE:Tagging_for_the_renderer VG Am 27. Februar 2014 23:16 schrieb Bernhard Weiskopf bweisk...@gmx.de: Hallo an alle, wie trägt man in OSM die Namen von Gewannen ein, dass sie in Mapnik angezeigt werden? Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wald aufteilen um Namen anzuzeigen?
Du hast schon mitbekommen, das die Darstellung von Namen aktuell eine etwas gössere Baustelle ist, an der ein Team in seiner Freizieit massiv arbeitet. Christoph Sent from my iDingens Am 27.02.2014 um 23:44 schrieb Bernhard Weiskopf bweisk...@gmx.de: Das zusammenhängende Naherholungsgebiet „Käfertaler Wald“ http://osm.org/go/0DwVt4CE-?m= ist untergliedert in vier Teile (Käfertaler Wald, Herrschaftswald, Sandhofer Wald und Neuwald), die bis jetzt mit „area = yes“ eingetragen sind, nun aber nicht mehr angezeigt werden. Außerdem laufen breite Schneisen (Autobahnen) durch, aber nicht an den Grenzen der einzelnen Wälder. Muss man den Käfertaler Wald jetzt aufteilen in viele Wälder und die zusammengehörenden Teile mit Relationen wieder zusammenfügen oder die Autobahnen über Relationen herausnehmen oder gibt es eine einfachere Lösung, dass die Namen der Wälder wieder angezeigt werden? Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eintrag von Gewann-Namen
Am 28.02.2014 00:08, schrieb Bernhard Weiskopf PS: Ich will für die Benutzer taggen (tagging for users) Nein: Du taggst für das Rendering, auch wenn DU das anders (für die user) nennst (wer sind die user). Das ist die grundsätzlich falsche Denkweise! Die richtige Denkweise wäre: OSM sammelt Geo-Daten welche die Wirklichkeit da draußen beschreiben. Und eine mögliche Benutzung dieser Daten ist das Rendering mit Mapnik (wobei sich dabei immer die Frage stellt welcher Stil dazu benutzt wird!). Aber das ist nur eine einzige Repräsentation der Daten - wenn auch eine prominente. Da gibt es aber viele andere mögliche Nutzungsmöglichkeiten der Daten. Somit ist die Fixierung auf den Rendere und insbesondere auf die Hauptkarte die grundsätzlich flasche Denkweise! BTW: selbst OSM.de verwendet ein anderes Rendering als OSM.org, welches ist jetzt der user? Oder die ÖPNV-Karte? Grüße, Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] mezza hackathon a Pavia - sabato
2014-02-26 22:16 GMT+01:00 Simone Cortesi sim...@cortesi.com: Ciao, ciao Sbiribizio, Sabas e il sottoscritto ci troveremo questo sabato a Pavia, presso SpazioGeco: http://www.spaziogeco.it/ Sarà una hackathon di una intera giornata finalizzata a tradurre materiale OSM in italiano e a mettere online una versione aggiornata di: http://openstreetmap.it/ Chiuque è il benvenuto, non è necessaria nessuna esperienza pregressa. da che ora a che ora, potrei collegarmi da remoto nel tardo pomeriggio -- -S -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Mancanza attribuzione mappa
2014-02-26 21:44 GMT+01:00 Vezzo vezz...@gmail.com: Ciao a tutti, ciao, oggi mi è arrivato a casa il calendario della raccolta differenziata con una mappa conosciuta, quella di OSM. Allora ho cercato subito se avevano messo l'attribuzione, ma non ho trovato nulla. Potete trovare una foto qui: https://www.dropbox.com/s/f6sw2hbo8xclpmk/IMG_20140226_193456.jpg Non ho ancora avuto modo di contattare nessuno, ma appena trovo un loro contatto vedo di mandare qualcosa. Mi date un'idea di cosa scrivere? si potrebbe recuperare quello che è stato scritto a quelli di terlizzi, direi che il problema è molto simile... buona serata a tutti -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] R: mezza hackathon a Pavia - sabato
A Pavia non ci posso essere. Ma posso salutarvi via Skype, se vi va, e se voleste assegnarmi un testo da tradurre, lo faccio volentieri Baci Ida Le mail ti raggiungono ovunque con BlackBerry® from Vodafone! -Original Message- From: Simone Cortesi sim...@cortesi.com Date: Wed, 26 Feb 2014 22:16:40 To: openstreetmap list - italianotalk-it@openstreetmap.org Reply-To: openstreetmap list - italiano talk-it@openstreetmap.org Subject: [Talk-it] mezza hackathon a Pavia - sabato Ciao, Sbiribizio, Sabas e il sottoscritto ci troveremo questo sabato a Pavia, presso SpazioGeco: http://www.spaziogeco.it/ Sarà una hackathon di una intera giornata finalizzata a tradurre materiale OSM in italiano e a mettere online una versione aggiornata di: http://openstreetmap.it/ Chiuque è il benvenuto, non è necessaria nessuna esperienza pregressa. -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] mezza hackathon a Pavia - sabato
Ciao, a me piacerebbe dare una mano ma non so se potrò esserci, forse qualche ora di mattina via skype. Magari vi mando prima di sabato qualche mockup da remixare come preferite :) Ciao Francesca Il giorno 27 febbraio 2014 09:47, sabas88 saba...@gmail.com ha scritto: Il giorno 27 febbraio 2014 09:32, Luca Delucchi lucadel...@gmail.com ha scritto: 2014-02-26 22:16 GMT+01:00 Simone Cortesi sim...@cortesi.com: Ciao, ciao Sbiribizio, Sabas e il sottoscritto ci troveremo questo sabato a Pavia, presso SpazioGeco: http://www.spaziogeco.it/ Sarà una hackathon di una intera giornata finalizzata a tradurre materiale OSM in italiano e a mettere online una versione aggiornata di: http://openstreetmap.it/ Chiuque è il benvenuto, non è necessaria nessuna esperienza pregressa. da che ora a che ora, potrei collegarmi da remoto nel tardo pomeriggio Circa 11-18, siamo aperti ad hangouts, irc, skype and company.. -- -S -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Salvare modifiche con iD
Dopo varie modifiche utilizzando iD da Firefox, vado a salvare e un messaggio di errore mi avverte che un nodo è stato modificato successivamente alla mia modifica e quindi mi viene impedito il salvataggio... Come faccio a salvare i dati dopo 2 ore di lavoro? Devo annullare tutto e ricominciare da capo? -- View this message in context: http://gis.19327.n5.nabble.com/Salvare-modifiche-con-iD-tp5797713.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Salvare le modifiche iD
Ciao! Non saprei come risolvere il tuo problema però ti consiglio di provare Josm. È davvero molto più comodo e potente di iD, e a mio parere è abbastanza facile da utilizzare a livello base e ha una curva di apprendimento poco ripida per le operazioni più complesse. Ciao! Davide Valsecchi ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] cinquepermille
2014-02-26 18:02 GMT+01:00 Simone Cortesi sim...@cortesi.com: puoi donare a wikimedia italia: http://wiki.wikimedia.it/wiki/Cinque_per_mille che da pochi giorni rappresenta la comunità italiana di OpenStreetMap. potevate anche comunicarlo prima di farlo -- -S -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] cinquepermille
Il 27 febbraio 2014 15:14, Luca Delucchi lucadel...@gmail.com ha scritto: 2014-02-26 18:02 GMT+01:00 Simone Cortesi sim...@cortesi.com: puoi donare a wikimedia italia: http://wiki.wikimedia.it/wiki/Cinque_per_mille che da pochi giorni rappresenta la comunità italiana di OpenStreetMap. potevate anche comunicarlo prima di farlo Mi pare se ne stia parlando da mesi, con vari messaggi anche in questa lista. Cristian ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Salvare le modifiche iD
Ciao, grazie per il consiglio. Ultimamente utilizzo iD per comodità, stranamente mi trovo meglio per molte cose su iD che su Josm, che ho utilizzato fino a non tanto tempo fa. Mi era capitato lo stesso errore anche su Josm (su una vecchia versione) e per risolvere ho dovuto ricancellare a ritroso tutti gli oggetti fino a quello incriminato, spero che nell'ultima versione sia stato corretto. L'errore è il seguente: Version mismatch: Provided 1, server had: 2 of Node 971983173 Mi sembra strano che non sia bypassabile una cosa del genere: ad esempio, se uno fa cento modifiche e solamente una genera l'errore perchè dovrei perdere tutte le altre 99? Secondo me questo è un vero e proprio bug da sistemare (la gestione dei conflitti), il programma (che sia iD, Josm o altro) dovrebbe saltare la modifica del nodo incriminato e scrivere però tutte le altre informazioni, altrimenti si perde un sacco di lavoro e tempo per niente. -- View this message in context: http://gis.19327.n5.nabble.com/Re-Salvare-le-modifiche-iD-tp5797743p5797771.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Salvare le modifiche iD
Am 27/feb/2014 um 13:12 schrieb Davide Valsecchi davide.val...@gmail.com: Non saprei come risolvere il tuo problema però ti consiglio di provare Josm. È davvero molto più comodo e potente di iD, e a mio parere è abbastanza facile da utilizzare a livello base e ha una curva di apprendimento poco ripida per le operazioni più complesse. +1 se ID ti consente di salvare un file potresti editare quello rimuovendo il nodo di conflitto ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Salvare le modifiche iD
Am 27/feb/2014 um 16:42 schrieb griphon grip...@tiscali.it: il programma (che sia iD, Josm o altro) dovrebbe saltare la modifica del nodo incriminato e scrivere però tutte le altre informazioni, altrimenti si perde un sacco di lavoro e tempo per niente. si, pare che si tratta di una imperfezione di ID, con Josm puoi gestire i conflitti e non perdi niente... ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Mancanza attribuzione mappa
Il 27/feb/2014 09:34 Luca Delucchi lucadel...@gmail.com ha scritto: ciao, Ciao si potrebbe recuperare quello che è stato scritto a quelli di terlizzi, direi che il problema è molto simile... Ok, provo a buttar giù qualcosa, ma non so a chi mandare, se a quelli che hanno fatto il depliant o l'azienda di raccolta rifiuti o entrambi. ciao -- Francesco ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Mancanza attribuzione mappa
Il 27/02/2014 19:56, Vezzo ha scritto: Il 27/feb/2014 09:34 Luca Delucchi lucadel...@gmail.com mailto:lucadel...@gmail.com ha scritto: ciao, Ciao si potrebbe recuperare quello che è stato scritto a quelli di terlizzi, direi che il problema è molto simile... Ok, provo a buttar giù qualcosa, ma non so a chi mandare, se a quelli che hanno fatto il depliant o l'azienda di raccolta rifiuti o entrambi. ciao -- Francesco Entrambi direi, in primis a chi ha eseguito il depliant ed in cc all'azienda. -- Gianluca Boero ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] GTFS in OpenData e su OSM
veramente un ottimo lavoro! complimenti! oltre ai suggerimenti dati dagli altri volevo aggiungere che il simbolino usato per indicare le fermate mi sembra troppo invasivo...opterei per una cosa più semplice e comunque più piccola rispetto ai simboli usati per i mezzi. eviterei anche di farli visualizzare agli zoom minori... my two cents ancora complimenti. Ps: leggendo bene l'about non ho capito benissimo (ah! maledetta la mia ignoranza...)...quindi questa non è realmente una mappa in tempo reale, ma avete usato gli orari dei mezzi per stimare e simulare i loro spostamenti, giusto? - Ciao, Aury -- View this message in context: http://gis.19327.n5.nabble.com/GTFS-in-OpenData-e-su-OSM-tp5797635p5797801.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] GTFS in OpenData e su OSM
si. Il progetto segue le api di ULM dove sostanzialmente uno script elabora il file degli orari e li simula facendo muovere i bus. sulla ML di SOD mi hanno chiesto di cambiare l'icona orginale delle fermate (era la H che simone cortesi sa spiegare in tedesco ;) ) e ho messo un'icona (CC0) che ho trovato. Il mio esperimento è cercare di capire quale può essere il metodo più semplice per creare una mappa trasporti dove non esiste un gestore che fornisce i tracciati ect. Per ora sto lavorando sul processo usato da Simone: OSM -- estrazione tramite OverPass del GeoJson e creazione quindi dei GTFS -- mappa giocattolo con i bus che si muovono. Domani proverà bus.meran.eu i cui autori hanno usato FreeGis.net e stanno per rilasciare i files (geojson) per i dati più tutti i files per la simulazione su mappa del resto. A diffenza di ULM, Merano non usa Node.js e penso sia più semplice da implementare. ps: vedrò di fare l'icona bus-stop più piccola ;-) Piersoft Il giorno 27/feb/2014, alle ore 20:32, Aury88 spacedrive...@gmail.com ha scritto: veramente un ottimo lavoro! complimenti! oltre ai suggerimenti dati dagli altri volevo aggiungere che il simbolino usato per indicare le fermate mi sembra troppo invasivo...opterei per una cosa più semplice e comunque più piccola rispetto ai simboli usati per i mezzi. eviterei anche di farli visualizzare agli zoom minori... my two cents ancora complimenti. Ps: leggendo bene l'about non ho capito benissimo (ah! maledetta la mia ignoranza...)...quindi questa non è realmente una mappa in tempo reale, ma avete usato gli orari dei mezzi per stimare e simulare i loro spostamenti, giusto? - Ciao, Aury -- View this message in context: http://gis.19327.n5.nabble.com/GTFS-in-OpenData-e-su-OSM-tp5797635p5797801.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it Francesco Piero Paolicelli TW: @piersoft STORE: GooglePlay/AppStore WWW: www.apposta.biz Sorry for typos, sent by mobile. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] aggiornamenti wtosm
Il giorno 17 febbraio 2014 13:25, Simone F. grop...@gmail.com ha scritto: 2014-02-17 10:58 GMT+01:00 Simone Cortesi sim...@cortesi.com: Ciao, mi sapete dire dove sbaglio? ... a pochi km a sud di milano, appare ancora come erroneamente posizionata a Lachiarella In breve: non sta sbagliando, le pagine di wikipedia-tags-in-osm devono essere aggiornate. Ho aggiornato i dati delle categorie e aggiunto: Fiumi d'Italia per regione (richiesta da fla) Chiese d'Italia per regione (richiesta da Paolo gatoselvadego Monegato) Montagne d'Italia per regione Malghe Alberi monumentali Dighe d'Italia Centrali termoelettriche in Italia Trafori ferroviari in Italia Trafori stradali in Italia Conventi d'Italia Autostrade in Italia Ricordo che, nel caso di oggetti composti da più way (es. fiumi) è preferibile aggiungere il tag wikipedia alla relazione, piuttosto che a ciascuna way. Per degli esempi basta cliccare sui link presenti per gli articoli già taggati. Luca ha aggiornato le pagine: http://geodati.fmach.it/gfoss_geodata/osm/wtosm/ Sono 8000 nuovi articoli da taggare e posti da controllare/perfezionare in OSM. Buon mapping :) Simone F. P.s. Questa pagina facilita la ricerca di articoli e categorie non mappabili: http://geodati.fmach.it/gfoss_geodata/osm/wtosm/non_mappable.html ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-ar] Numeracion de calles
Hola Hernan. Es la primera vez que mando un correo a esta lista de correo. Espero que lo haya hecho bien. Esta perfecto. La aplicación que usas es la más practica lejos (especialmente cuando salis a caminar, etc.). También podés interpolar para agregar las numeraciones, es mucho más rápido, más práctico, pero claro, menos preciso. En este artículo en la wiki de OSM Argentina: http://wiki.openstreetmap.org/wiki/Argentina:Altura_de_las_Calles se explican brevemente las dos maneras de agregar numeraciones, y también tenés un link que te lleva a un tutorial para interpolar. Si tenés alguna otra duda, pegate una pasada por el foro de Argentina: http://forum.openstreetmap.org/viewforum.php?id=49. El sábado y domingo vamos a realizar un Mapping Party Virtual, dónde la principal tarea es agregar numeraciones en Godoy Cruz, Mendoza. Si te interesa participar, es un buen lugar para despejarte todas las dudas. Un saludo! El 27 de febrero de 2014, 13:54, Hernán Javier López hernan.lo...@gmail.com escribió: Hola: Cada tanto colaboro con algunas ediciones menores en OpenStreetMap (http://www.openstreetmap.org/user/Hernan) y desde hace tiempo que quería ayudar, al menos en la zona que me muevo con las numeraciones de las alturas de las calles. Acabo de hacer una primera prueba usando esta aplicacion https://play.google.com/store/apps/details?id=de.enaikoon.android.keypadmapper3hl=es porque la verdad que el método manual, no lo termino de entender. Hice una pequeña prueba con mi cuadra http://www.openstreetmap.org/edit#map=18/-34.63270/-58.52733 y quería que me digan, si el método es correcto, si la aplicación sube los datos en forma correcta o no. Si esta mal, no hay problema en que lo borre alguien que sepa mas cual es el método correcto o lo borro yo, es solo que me pareció una forma bastante sencilla de hacerlo y si sirve, puedo salir a pasear con mis hijos por el barrio e ir haciéndolo. Si la forma de hacerlo es otra, y me pueden enviar donde estudiar la información, veo de hacerlo. Espero sus comentarios :) Saludos Hernan ___ Talk-ar mailing list Talk-ar@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ar ___ Talk-ar mailing list Talk-ar@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ar
