[OSM-talk-be] Cycleways tag as oneway=yes ?
Tried out route planner for bikes and saw in my region that the planner takes the wrong side of the road. https://graphhopper.com/maps/?point=50.788276%2C3.133957point=Kortrijkstraat%2C%208930%2C%20Menin%2C%20Belgiumvehicle=bikeelevation=truelayer=Lyrk The roundabout I will correct it to oneway=yes but other roads with the lane on both side of the roads must they been change one by one to oneway=yes -- Jakka ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Cycleways tag as oneway=yes ?
This roundabout was already in the sytem with all the details separated footway, cycle way, highway. hope better link. (How taken a link of josm screen ? permalink?) https://graphhopper.com/maps/?point=50.788276%2C3.133957point=50.794787%2C3.137348vehicle=bikeelevation=truelayer=Lyrk Marc Gemis schreef op 11/11/2014 om 11:57: Weird, I always thought that you do not have to add oneway=yes to a roundabout, in case it is tagged as junction=roundabout. For the route you specified, I don't see any separately drawn cycleways. Anyway, do not forget to tag the main road with bicycle=use_sidepath in such case. And to properly connect the cycleway with all crossings, including T-crossing on the other side of the road. regards m On Tue, Nov 11, 2014 at 11:41 AM, Jakka vdmfrank...@gmail.com mailto:vdmfrank...@gmail.com wrote: Tried out route planner for bikes and saw in my region that the planner takes the wrong side of the road. https://graphhopper.com/maps/?__point=50.788276%2C3.133957__point=Kortrijkstraat%2C%__208930%2C%20Menin%2C%__20Belgiumvehicle=bike__elevation=truelayer=Lyrk https://graphhopper.com/maps/?point=50.788276%2C3.133957point=Kortrijkstraat%2C%208930%2C%20Menin%2C%20Belgiumvehicle=bikeelevation=truelayer=Lyrk The roundabout I will correct it to oneway=yes but other roads with the lane on both side of the roads must they been change one by one to oneway=yes -- Jakka ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Cycleways tag as oneway=yes ?
I think the correct key is : http://wiki.openstreetmap.org/wiki/Key:oneway:bicycle Since it is standard to allow bicycles to use both direction, also in a one-way street it's allowed unless specifically restricted. Glenn On 11-11-14 11:41, Jakka wrote: Tried out route planner for bikes and saw in my region that the planner takes the wrong side of the road. https://graphhopper.com/maps/?point=50.788276%2C3.133957point=Kortrijkstraat%2C%208930%2C%20Menin%2C%20Belgiumvehicle=bikeelevation=truelayer=Lyrk The roundabout I will correct it to oneway=yes but other roads with the lane on both side of the roads must they been change one by one to oneway=yes -- Everything is going to be 200 OK.http://wiki.openstreetmap.org/wiki/Key:oneway:bicycle ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Cycleways tag as oneway=yes ?
Sorry but oneway=yes just means you can only drive in the direction of the way. It has nothing to do with going opposite. I quote: The oneway tag is used to indicate the access restriction on highways and other linear features as appropriate. So it's an access restriction. On highway=cycleway it's the same , standard is that you can use it both ways unless specified you can't. There are seperate cycleways on this road we are talking about btw but they are restricted with oneway=yes. Glenn On 11-11-14 14:44, Ben Laenen wrote: On Tuesday 11 November 2014 13:12:15 Glenn Plas wrote: I think the correct key is : http://wiki.openstreetmap.org/wiki/Key:oneway:bicycle Since it is standard to allow bicycles to use both direction, also in a one-way street it's allowed unless specifically restricted. No, it's the opposite: oneway=yes restricts all drivers to go the opposite direction, whether you're driving a car, a bicycle, a horse or herding a cow or whatever your mode of transport (except on foot, you're not a driver then). Ben ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be -- Everything is going to be 200 OK. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Cycleways tag as oneway=yes ?
Gilbert, Dit is geen discussie over de wegcode maar over de betekenis van tags en het resultaat ervan. Het intereseert me zelfs niet wat de wegcode ervan vindt in het kader van deze materie. Ik heb het dus niet over de wegcode maar over de betekenis van de keys. Laat dit duidelijk zijn dat hier wel af en toe een groot verschil tussen zit.. De standaard is -evenals wagens- mogen fietsers in OSM op het fietspad in 2 richtingen rijden tenzij restricties worden gelegd. http://wiki.openstreetmap.org/wiki/Tag:highway%3Dcycleway Bij: cycleway, zoals highway kan je daar in 2 richtingen over rijden tenzij verboden. De highway tag werkt hetzelfde. Dus zonder restricties is dat de standaard. op junction=roundabout is de oneway=yes impliciet, maar niet op de aparte cycleway, dat is namelijk geen junction. Hebben jullie dit stuk al opengedaan in JOSM , het is echt wel een aparte cycleway, dus heeft geen bal te maken met die junction. Kijk naar de tags aub. Glenn On 11-11-14 13:39, Gilbert Hersschens wrote: Moet een bug in de route planner zijn. OSM vermeldt dat ronde punten impliciet éénrichtingsstraten zijn: http://wiki.openstreetmap.org/wiki/Tag:junction%3Droundabout (definitie: A roundabout is a /one-way/ street with /right-of-way/ and a /non-traversable http://wiki.openstreetmap.org/wiki/Non-traversable/ center island.). @Glenn: kijk de wegcode nog eens na. Voor fietsers gelden dezelfde regels als voor automobilsten. Ze mogen enkel tegen de opgelegde richting in rijden als het betreffende onderbord aanwezig is (dwz de regel is dat het NIET mag). Zie http://webshop.bivv.be/frontend/files/products/pdf/2fea42ac8b1b22e59ef8d5ea77aaf906/fietsersendewegcode.pdf, blz 27 en verder. Gilbert On 11 November 2014 11:41, Jakka vdmfrank...@gmail.com mailto:vdmfrank...@gmail.com wrote: Tried out route planner for bikes and saw in my region that the planner takes the wrong side of the road. https://graphhopper.com/maps/?__point=50.788276%2C3.133957__point=Kortrijkstraat%2C%__208930%2C%20Menin%2C%__20Belgiumvehicle=bike__elevation=truelayer=Lyrk https://graphhopper.com/maps/?point=50.788276%2C3.133957point=Kortrijkstraat%2C%208930%2C%20Menin%2C%20Belgiumvehicle=bikeelevation=truelayer=Lyrk The roundabout I will correct it to oneway=yes but other roads with the lane on both side of the roads must they been change one by one to oneway=yes -- Jakka _ Talk-be mailing list Talk-be@openstreetmap.org mailto:Talk-be@openstreetmap.org https://lists.openstreetmap.__org/listinfo/talk-be https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be -- Everything is going to be 200 OK. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Cycleways tag as oneway=yes ?
This is actually quite interesting road to dive in deeper. I notice a few problems with this roundabout. https://www.openstreetmap.org/changeset/26707718#map=19/50.78871/3.13953 There is no connection between Moeskroenstraat en the cycleway. This would pop up when Validating changes before upload. There is no bridge nor tunnel so I believe that it's wrong to not intersect these 2. Also cycleway 250518756 is missing the oneway. I think Jakka made it a lot better and after this changeset a few hours ago. That router will probably work better when they have access to this new data, unless it is not respecting the oneway tag, then it will not change. I made some corrections but left the oneway in the middle for now. Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Cycleways tag as oneway=yes ?
Glenn, ik zie nergens een cycleway op http://osm.org/go/0EgP1kjK2?m=way=109638123 ? (ook n iet in JOSM) 2014-11-11 14:52 GMT+01:00 Glenn Plas gl...@byte-consult.be: Gilbert, Dit is geen discussie over de wegcode maar over de betekenis van tags en het resultaat ervan. Het intereseert me zelfs niet wat de wegcode ervan vindt in het kader van deze materie. Ik heb het dus niet over de wegcode maar over de betekenis van de keys. Laat dit duidelijk zijn dat hier wel af en toe een groot verschil tussen zit.. De standaard is -evenals wagens- mogen fietsers in OSM op het fietspad in 2 richtingen rijden tenzij restricties worden gelegd. http://wiki.openstreetmap.org/wiki/Tag:highway%3Dcycleway Bij: cycleway, zoals highway kan je daar in 2 richtingen over rijden tenzij verboden. De highway tag werkt hetzelfde. Dus zonder restricties is dat de standaard. op junction=roundabout is de oneway=yes impliciet, maar niet op de aparte cycleway, dat is namelijk geen junction. Hebben jullie dit stuk al opengedaan in JOSM , het is echt wel een aparte cycleway, dus heeft geen bal te maken met die junction. Kijk naar de tags aub. Glenn On 11-11-14 13:39, Gilbert Hersschens wrote: Moet een bug in de route planner zijn. OSM vermeldt dat ronde punten impliciet éénrichtingsstraten zijn: http://wiki.openstreetmap.org/wiki/Tag:junction%3Droundabout (definitie: A roundabout is a /one-way/ street with /right-of-way/ and a /non-traversable http://wiki.openstreetmap.org/wiki/Non-traversable/ center island.). @Glenn: kijk de wegcode nog eens na. Voor fietsers gelden dezelfde regels als voor automobilsten. Ze mogen enkel tegen de opgelegde richting in rijden als het betreffende onderbord aanwezig is (dwz de regel is dat het NIET mag). Zie http://webshop.bivv.be/frontend/files/products/pdf/2fea42ac8b1b22e59ef8d5ea77aaf906/fietsersendewegcode.pdf , blz 27 en verder. Gilbert On 11 November 2014 11:41, Jakka vdmfrank...@gmail.com mailto:vdmfrank...@gmail.com wrote: Tried out route planner for bikes and saw in my region that the planner takes the wrong side of the road. https://graphhopper.com/maps/?__point=50.788276%2C3.133957__point=Kortrijkstraat%2C%__208930%2C%20Menin%2C%__20Belgiumvehicle=bike__elevation=truelayer=Lyrk https://graphhopper.com/maps/?point=50.788276%2C3.133957point=Kortrijkstraat%2C%208930%2C%20Menin%2C%20Belgiumvehicle=bikeelevation=truelayer=Lyrk The roundabout I will correct it to oneway=yes but other roads with the lane on both side of the roads must they been change one by one to oneway=yes -- Jakka _ Talk-be mailing list Talk-be@openstreetmap.org mailto:Talk-be@openstreetmap.org https://lists.openstreetmap.__org/listinfo/talk-be https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be -- Everything is going to be 200 OK. ___ 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] Cycleways tag as oneway=yes ?
On 2014-11-11 16:49, Gilbert Hersschens wrote : @André: pls read again (you provided the link yourself): Some tags (such as junction http://wiki.openstreetmap.org/wiki/Key:junction=roundabout http://wiki.openstreetmap.org/wiki/Tag:junction%3Droundabout, highway http://wiki.openstreetmap.org/wiki/Key:highway=motorway http://wiki.openstreetmap.org/wiki/Tag:highway%3Dmotorway and others) imply *oneway*=yes and _therefore the oneway tag is optional_. Hence it doesn't need the tag oneway=yes. This is exactly what my first sentence says : A roundabout needs no oneway=yes http://wiki.openstreetmap.org/wiki/Oneway#Implied_oneway_restriction. Thanks for concurring and stressing it so much. Unless, of course, it means something else. You don't say what it is. But I don't say anywhere that oneway=yes is needed anywhere anyway. André. Regards, Gilbert On 11 November 2014 14:40, André Pirard a.pirard.pa...@gmail.com mailto:a.pirard.pa...@gmail.com wrote: On 2014-11-11 11:41, Jakka wrote : Tried out route planner for bikes and saw in my region that the planner takes the wrong side of the road. https://graphhopper.com/maps/?point=50.788276%2C3.133957point=Kortrijkstraat%2C%208930%2C%20Menin%2C%20Belgiumvehicle=bikeelevation=truelayer=Lyrk The roundabout I will correct it to oneway=yes A roundabout needs no oneway=yes http://wiki.openstreetmap.org/wiki/Oneway#Implied_oneway_restriction and the bicycles must follow the same restrictions as all vehicles unless an exception is tagged http://wiki.openstreetmap.org/wiki/Oneway#Sub_keys_.2F_exceptions (an exception means that the bicycles are normal vehicles without an exception). The direction of the way must be in the direction of the oneway and it looks correct. It's looks like a bug of the software. If you change the vehicle to car, it makes the same roundabout mistake. You should report it. Wonderful router you're showing. Does it use often updated data? but other roads with the lane on both side of the roads must they been change one by one to oneway=yes Do you mean a two-lane road or something else? Give the URL of an example. hope better link. (How taken a link of josm screen ? permalink?) Click FileDownload from OSMBounding Box and you have a OSM.org URL to copypaste down below. I think that's what you're asking. It's nice to see you talk here, Jakka. And thanks for the English ! ;-) André. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Cycleways tag as oneway=yes ?
I noticed my misinterpretation myself indeed - after the facts. My bad. I wasn't claiming that oneway=yes doesn't apply to cyclists, I was saying that the 'wegcode' actually allows bicycles to use the cycleway in the opposite direction. - and that was totally wrong after deeper researching. So I was trying to point out the difference between the way OSM goes about this and the real life situation. I came to the following conclusion: By default, cycleways as tagged in OSM do allow cycletraffic both ways, since they do not implicitly put oneway=yes on it. But that’s not what the .be law says... What you're claiming is correct, I was trying to point out that the keys put on the junction=roundabout do not have influence when the cycleway was drawn separately which is true in the case of this separation. Now, I only checked the situation after Jakka worked on it but didn't realise this before sending my replies, so I failed to see the initial situation where the routing problem claims applied upon. The conclusion I'm drawing from all this is that in Belgium, most seperate cycleways should probably be tagged oneway=yes. It's got everything to do with the placement of the D7/D9 signs being to the right or to the left of the sign. And then there are some exceptions as well to this rule depending on the sitation. So I checked with google streetview, and I believe that the oneway tags are now all correct on the cycleways that are located around the roundabout. And I learned something today, you can't use the cycleway in both directions by default! I always figured you could. Glenn On 11-11-14 16:46, Ben Laenen wrote: On Tuesday 11 November 2014 14:51:07 Glenn Plas wrote: Sorry but oneway=yes just means you can only drive in the direction of the way. It has nothing to do with going opposite. Yeah, sorry, used a wrong word there after I rewrote that sentence. Should have been: No, it's the opposite: oneway=yes prohibits all drivers to go in the opposite direction, whether you're driving a car, a bicycle, a horse or herding a cow or whatever your mode of transport (except on foot, you're not a driver then). since you were claiming oneway=yes doesn't apply to cyclists. Ben ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be -- Everything is going to be 200 OK. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Cycleways tag as oneway=yes ?
2 problems: You're not checking the roundabout I think we were talking about. https://www.openstreetmap.org/#map=17/50.78823/3.14081 Check in JOSM for the latest data. The tiles do not get regenerated at the changeset rate. It will take some time to proliferate. That's exactly why we talking next to eachother. Jakka worked on it, I did a few fixes + validation. Then I fixed my own mistakes in fixing On 11-11-14 17:11, Gilbert Hersschens wrote: Glenn, ik zie nergens een cycleway op http://osm.org/go/0EgP1kjK2?m=way=109638123 ? (ook n iet in JOSM) ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Cycleways tag as oneway=yes ?
Hi, highway=cycleway is distinct from another highway=* and uses its own distinct oneway=* oneway bicycle exceptions in the same highway are described here http://wiki.openstreetmap.org/wiki/Oneway#Sub_keys_.2F_exceptions. The mapping of cycleway=* alongside a oneway highway=* is described here http://wiki.openstreetmap.org/wiki/Bicycle#Cycle_lanes_in_oneway_motor_car_roads. That certainly applies to implicit oneway like roundabouts except that, of course, oneway=yes must be removed. One problem of that wiki is that the same things are or are not repeated partially in several, sometimes many, places like /*oneway*/ and /*cycleway*/ and that they often do not refer to better explanations like /*Bicycle*/. André. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Cycleways tag as oneway=yes ?
On 2014-11-11 17:57, Glenn Plas wrote : ... That's exactly why we talking next to eachother. Jakka worked on it, I did a few fixes + validation. Then I fixed my own mistakes in fixing Yes, that reminds me - look at that mistake - I don't see any - that's because I corrected it Yes, please, if someone is doing something, don't rush modifying it, even if brilliantly, give him advices and let him see the effects of what he's doing and learning instead of what happens miraculously. André. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Cycleways tag as oneway=yes ?
Jakka, please do not use ways to represent lanes. The Moeskroenstraat coming from the east (before the roundabout) should not be split until you see the white divider at the last moment. Before that it should be tagged as lanes=2, turn:lanes=none|slight_right or through|slight_right I have been changing this all over Flanders in the past 6 months. Haven't done a lot in West-Vlaanderen yet. The Germans will probably have a week assignment soon to fix those kind of things in Germany. In case you understand a little German this https://drive.google.com/file/d/0B_3PJBM5cOz5dUlXSUt1d29FXzg/view might be a good read regards m ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Cycleways tag as oneway=yes ?
On Tue, Nov 11, 2014 at 2:40 PM, André Pirard a.pirard.pa...@gmail.com wrote: Wonderful router you're showing. Does it use often updated data? I thought the routing data was updated daily, the map is updated more frequent. Remember that this router does not honor turn restrictions at this moment. In case you want to test that, you can use http://map.project-osrm.org/. I believe there is some beta code to integrate both routers into osm.org. regards m ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Cycleways tag as oneway=yes ?
Andre, In case you look for more routers, try this one. It's very fast, I consider it a light weight one. There still work to be done on it, not perfect but worth diving into it. http://www.routino.org Glenn On 11-11-14 19:16, Marc Gemis wrote: On Tue, Nov 11, 2014 at 2:40 PM, André Pirard a.pirard.pa...@gmail.com mailto:a.pirard.pa...@gmail.com wrote: Wonderful router you're showing. Does it use often updated data? I thought the routing data was updated daily, the map is updated more frequent. Remember that this router does not honor turn restrictions at this moment. In case you want to test that, you can use http://map.project-osrm.org/. I believe there is some beta code to integrate both routers into osm.org http://osm.org. regards m ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be -- Everything is going to be 200 OK. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
[OSM-talk] OSMGeoWeek coming up
OSMGeoWeek is building steam. Join us. 14 events and counting ( http://osmgeoweek.org/events/) planned during the week November 15-22, celebrating geography, education, and OpenStreetMap. We'll be launching TeachOSM. The amazing cartographers at National Geographic have invited the free and open map of the entire world for the flagship food mapping party, on November 21 in DC. Sign up here: https://www.eventbrite.com/e/national-geographic-geography-awareness-week-mapping-party-tickets-13995325395 Mapping tasks (http://osmgeoweek.org/projects/) and planning guides ( http://osmgeoweek.org/plan/) are being continually updated. Would be excellent to have you involved, even in a small way! It's not too late to organize an event in your part of the world (at a formal school, or out in the school of life) and we'll promote on the site, and support however we can. -Mikel ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] State of the Map US 2015 in New York, NY, June 6-8
On Tue, Nov 11, 2014 at 11:04 AM, Michael Kugelmann michaelk_...@gmx.de wrote: On 11.11.2014 00:16, Eugene Alvin Villar wrote: But I would rather see New York as the SotM 2015 and Venice as the SotM EU 2015. So I think that the OSMF should cooperate with OSM US and declare the winning New York bid as the State of the Map 2015. NY was on the bid list of the SOTM but it was removed = so for me it seems that they had decided not to go for the international conference. I submitted the UN conference for SotM and then removed it when it was officially accepted as SotM-US. It's not that we didn't want an international aspect -- this will certainly be the largest and most international SotM to date. It's that the US org has a demonstrated track record of running large conferences very well, and it seemed like a better partner for this. For context, during this submission process the Buenos Aires event didn't post a schedule until the last minute, had sponsorship issues with logos not correct, not up on time, etc. This conference will be very visible and we can't have stuff like that happening, so we opted for the US group. I'm just a single member of the organizing committee, but assuming both boards could work together and agreed on this, I personally would be happy to combine the conferences. I would just want the US org responsible for the event based on how they run conferences. But the more people at the UN the merrier! -Randy ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMGeoWeek coming up
Here's one more for you: Learning QGIS and OpenStreetMap - Three short talks and plenty of QA Wednesday, 19 November 2014 from 7:00 PM to 9:00 PM (EST) Learning Labs 481 Queen St W Classroom B Toronto, ON M5V 2A9 Canada ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Location SOTM 2015?
Hi, On 11/10/2014 08:04 PM, Michael Kugelmann wrote: as I didn't read anything about it: was there an announcement about the location for the 2015 SOTM at the 2014 SOTM Buenos Aires? IIRC there was a statement about the intention to announce the 2015 locataion there... The only things announced at SOTM 2014 were a SOTM-Latin America for 2016 (perhaps in Ecuador? not sure ATM) and a SOTM-US for 2015 in New York Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Location SOTM 2015?
I think the Sotm latinoamérica 2016 will be in Bolivia, not Ecuador. El 11/11/2014 16:51, Frederik Ramm frede...@remote.org escribió: Hi, On 11/10/2014 08:04 PM, Michael Kugelmann wrote: as I didn't read anything about it: was there an announcement about the location for the 2015 SOTM at the 2014 SOTM Buenos Aires? IIRC there was a statement about the intention to announce the 2015 locataion there... The only things announced at SOTM 2014 were a SOTM-Latin America for 2016 (perhaps in Ecuador? not sure ATM) and a SOTM-US for 2015 in New York Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ 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] Location SOTM 2015?
Hi, On 11/11/2014 08:59 PM, Rafael Avila Coya wrote: I think the Sotm latinoamérica 2016 will be in Bolivia, not Ecuador. Of course! My bad, sorry. Still a bit lagged from the 13 hour flight home ;) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Talk-us] Fix a Forest - experimental tiles from US Forest Service data
On Tue, Nov 11, 2014 at 10:29 AM, Richard Fairhurst rich...@systemed.net wrote: Hope these are helpful, and let me know of any further suggestions. Richard, Thanks for doing this. The selection of color and lines make for quick addition. Suggestion - set the tile background to transparent so we can see underlying image in JOSM. Thanks, 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] Fix a Forest - experimental tiles from US Forest Service data
On 11/11/2014 10:29 AM, Richard Fairhurst wrote: I've created a set of tiles from US Forest Service road data for the 155 US National Forests. It's worth noting that a green area denotes a US National Forest, which does not imply it's got trees, which is necessary for an OSM forest. Thanks for putting this together. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Talk-us] Fix a Forest - experimental tiles from US Forest Service data
On 11/11/2014 20:57, Clifford Snow wrote: Suggestion - set the tile background to transparent so we can see underlying image in JOSM. I can certainly have a look at doing that. Do you/anyone know whether transparent tiles would still be usable in iD? cheers Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Adding Wikidata tags to 70k items automatically
Andy Mabbett a...@pigsonthewing.org.uk wrote: On 27 August 2014 17:47, Edward Betts edw...@4angle.com wrote: I'd like to annotate these 70k objects in OSM with a Wikidata tag automatically. Can we now move forward with this? I'll generate a fresh list of Wikidata items. -- Edward. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Location SOTM 2015?
Hi, on talk-latm is a discussion ongoing to have a SotM-LA in 2015 as well. ;-) -- ## Manfred Reiter - mobile - please excuse typos and brevity Am 11.11.2014 15:02 schrieb Frederik Ramm frede...@remote.org: Hi, On 11/11/2014 08:59 PM, Rafael Avila Coya wrote: I think the Sotm latinoamérica 2016 will be in Bolivia, not Ecuador. Of course! My bad, sorry. Still a bit lagged from the 13 hour flight home ;) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ 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] State of the Map US 2015 in New York, NY, June 6-8
Although it is situated in New York City, the//land occupied by the United Nations Headquarters and the spaces of buildings that it rents are under the sole administration of the United Nations. They are technically extraterritorial through a treaty agreement with the U.S. government (1). The General Assembly Hall is the largest room in the United Nations, with seating capacity for over 1,800 people. (2) (1) http://en.wikipedia.org/wiki/Headquarters_of_the_United_Nations (2) http://www.samrohn.com/360-panorama/united-nations-general-assembly-hall-nyc/ (a nice 3-D panorama of this historical hall) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Suche Ansprechpartner und Lösungsvorschlag (elotse)
Am 9. November 2014 11:14 schrieb Manuel Reimer manuel.s...@nurfuerspam.de : Ich hätte mir sehr gewünscht, dass die Kollegen früher mit der Kommunity gesprochen hätten. Ja, das wäre besser gewesen. +1 Aber auch jetzt kann man sich durchaus noch mit dem zu Grunde liegenden Problem befassen und sich auf ein sauberes allgemeingültiges Tagging einigen. Dei ebusiness-Tags fliegen dann natürlich zugunsten des allgemeinen Taggings raus. Sehe ich auch so, es gibt keinen erkennbaren Grund, solche tags zu verwenden (und überwiegend sind das keine Informationen im Sinne unserer Datenbank): ebusinesslotse=yes was soll das heissen, wo ist es dokumentiert? ebusinesslotse:note=Mittelstand-Digital, gefördert vom BMWI das ist kein note in OSM, da es kein Hinweis für andere Mapper ist. Das gefördert vom BMWI können sie sich aufs Briefpapier schreiben und nicht in unsere db ;-) ebusinesslotse:profil=Online Marketing, IT-Sicherheit ebusinesslotse:role=Projektleitung ist das eine formale Liste (dann sollte ein ; zur Trennung mehrerer Werte verwendet werden, keine Groß- und Kleinschreibung, keine deutschen Werte, keine Leerzeichen, am Besten eine tag-Definitionsliste im Wiki erstellen)? Oder ein Freitext (Werbung)? ebusinesslotse:url=www.ebusiness-lotse-thueringen.de entweder ist das eine weitere Webseite des POI (dann key url) oder die Hauptwebseite (dann key website) oder es ist Werbung für dieses E-Business-Lotsen Förderprogramm und gehört nicht in die db. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ist dies ein Bug in JOSM -- diverse Punkte erstellt, aber nichts zum Uploaden?
Hallo. Am 10.11.2014 um 22:27 schrieb Andreas Schmidt: Als ich Uploaden wollte, fiel mir auf, dass ich gar keine Ortsangabe weiß. Also habe ich im JOSM nach dem nächsten Ort geschaut, dessen Daten in JOSM heruntergeladen und den Ortsnamen herauskopiert. Hast du dabei vielleicht eine neue Ebene erzeugt und später versehentlich bei dieser neuen Ebene Hochladen angeklickt? Das würde passen, denn wenn du in dieser Ebene nichts verändert hast, dann gibt es eben nichts zum Hochladen. Gruß, Bernd signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche Ansprechpartner und Lösungsvorschlag (elotse)
Manfred A. Reiter wrote on 10.11.2014 01:32: Am 8. November 2014 16:46 schrieb Andreas Neumann andr-neum...@gmx.net: Zitat: Das Ganze ist schwer zu verstehen, das weiß ich. Lass also die Einträge bitte beide bestehen, es ist wirklich das Beste in diesem Fall eine Adresse / Einrichtung eben doppelt zu haben. Diesen Ton halte ich für völlig unangemessen! Das Ganze ist schwer zu verstehen ... spinnt der? Vorsicht, das kann zwei Dinge bedeuten: Unser Setup ist leider nicht so flexibel wie wir gerne hätten, daher ist es von außen nicht so klar, warum wir das so gemacht haben. oder Das ist so super komplex, da sind Sie zu doof das zu verstehen Ich habe erstmal keine Veranlassung von letzterer Intention auszugeben. -- Grüße Holger Jeromin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche Ansprechpartner und Lösungsvorschlag (elotse)
Hallo Holger, Am 11. November 2014 15:32 schrieb Holger Jeromin mailgm...@katur.de: Manfred A. Reiter wrote on 10.11.2014 01:32: Am 8. November 2014 16:46 schrieb Andreas Neumann andr-neum...@gmx.net : Zitat: Das Ganze ist schwer zu verstehen, das weiß ich. Lass also die Einträge bitte beide bestehen, es ist wirklich das Beste in diesem Fall eine Adresse / Einrichtung eben doppelt zu haben. Diesen Ton halte ich für völlig unangemessen! Das Ganze ist schwer zu verstehen ... spinnt der? Vorsicht, das kann zwei Dinge bedeuten: Unser Setup ist leider nicht so flexibel wie wir gerne hätten, daher ist es von außen nicht so klar, warum wir das so gemacht haben. oder Das ist so super komplex, da sind Sie zu doof das zu verstehen Ich habe erstmal keine Veranlassung von letzterer Intention auszugeben. Bist Du wirklich der Meinung, dass bei ersterer Vermutung nicht auch zwei Zeilen zur Erläuterung möglich gewesen wären, statt Das Ganze ist schwer zu verstehen, das weiß ich. Lass also die Einträge bitte beide bestehen, ... Ich finde eine solche Antwort nach wie vor arrogant und absolut unangemessen, insbesondere, wenn ich auf Leistungen anderer unentgeltlich zurückgreife. LG M. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche Ansprechpartner und Lösungsvorschlag (elotse)
Nutzer DD1GJ http://www.openstreetmap.org/user/DD1GJ hat soeben den von mir gelöschten Node in abgewandelter Form wieder hergestellt http://www.openstreetmap.org/changeset/26704923 Nun ist ebusiness als Wert beim Office-Tag eingefügt worden. Da es in der Wiki nicht definiert ist, werde ich dem Nutzer eine Frist setzen dies Nachzuholen (inkl. Diskussion mit der Community), ansonten werde ich den Tag wieder löschen. MfG Andreas Nun ist das On 08.11.2014 14:40, Andreas Neumann wrote: Hallo, mir ist gerade ein mehrschichtiges Problem unter gekommen. In Ilmenau existiert im TechnologieTerminal A die Firma tranSIT GmbH https://www.openstreetmap.org/node/3103940301. Sie wurde von Nutzer CornyJoe https://www.openstreetmap.org/user/CornyJoe eingetragen und von mir noch etwas verfeinert. Er hat weitere Tags ebusinesslotse* verwendet, die leider bisher nirgends definiert sind. Da sie aber einen eigenen Namensraum eröffnen und bestehende Tagging-Schemata nicht tangieren, war es mir egal (zumal er mehrere Firmen in ganz Deutschland so definiert hat). Bis hier her kein Problem, aber evtl. wichtig für Runde 2: Nutzer elotse-thueringen http://www.openstreetmap.org/user/elotse-thueringen legte einen neuen Node für die tranSIT GmbH https://www.openstreetmap.org/node/3132885744 an. Ich löschte den Node, da er für mich eindeutig redundant ist und schrieb den Nutzer an. Nun kam als Antwort zurück: die Gründe für die doppelte Anlegung ist das Bundesministerium für Wirtschaft und Energie, die gerne möchte, dass der eBusiness-Lotse Thüringen einen eigenen Eintrag bekommt. Der Unterschied liegt auch nicht nur in der Mailadresse, sondern vielmehr in den Tätigkeitsschwerpunkten. Meine Fragen sind nun: - Sollen unterschiedliche Tätigkeitsbereiche als eigenständige Firmen in OSM eingetragen werden? Bzw. gibt es ein besseres Tagging, die sehr spezielle Problem abdecken (zumal es für außenstehende auch oft schwer nachprüfbar und wartbar ist) - Wer im BUNDESMINISTERIUM hat entsprechende Anweisungen ausgegeben? - Bzw. gibt es unsererseits einen Ansprechpartner im Bundesministerium, um über die Problematik zu reden? MfG Andreas PS: ich bin immer noch die Meinung, das ein Node reicht und eventuelle Tätigkeitsbereiche als Attribut drangepappt werden können, bzw. nicht als eigenständig getaggte Firma reingehören. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de -- Andreas Neumann http://Map4Jena.de http://Stadtplan-Ilmenau.de signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche Ansprechpartner und Lösungsvorschlag (elotse)
Manfred A. Reiter wrote on 11.11.2014 15:57: Am 11. November 2014 15:32 schrieb Holger Jeromin mailgm...@katur.de: Manfred A. Reiter wrote on 10.11.2014 01:32: Am 8. November 2014 16:46 schrieb Andreas Neumann andr-neum...@gmx.net Zitat: Das Ganze ist schwer zu verstehen, das weiß ich. Lass also die Einträge bitte beide bestehen, es ist wirklich das Beste in diesem Fall eine Adresse / Einrichtung eben doppelt zu haben. Diesen Ton halte ich für völlig unangemessen! Das Ganze ist schwer zu verstehen ... spinnt der? Vorsicht, das kann zwei Dinge bedeuten: Unser Setup ist leider nicht so flexibel wie wir gerne hätten, daher ist es von außen nicht so klar, warum wir das so gemacht haben. oder Das ist so super komplex, da sind Sie zu doof das zu verstehen Ich habe erstmal keine Veranlassung von letzterer Intention auszugeben. Bist Du wirklich der Meinung, dass bei ersterer Vermutung nicht auch zwei Zeilen zur Erläuterung möglich gewesen wären, statt Natürlich wäre es möglich oder sogar sinnvoll gewesen. Ich wollte nur sagen, dass die emotionale Ebene bei reinen Textmails zu einer unbekannten Person nur über mehr Text oder zum Beispiel Smilies transportiert wird. Bei einem Gespräch per Sprache oder sogar zusätzlichen Bild (face2face) fällt es viel einfacher die Intention herauszulesen. -- Grüße Holger ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche Ansprechpartner und Lösungsvorschlag (elotse)
Ich wuerde gerne in diesem Kontext auf ein generelles Problem verweisen, fuer das, sowei ich weiss OSM (noch) keine einfache Antwort hat: meshing of databases. Dieses Beispiel ist eines von vielen. Uach ich habe einige solche Sachen in petto, wo ich noch nicht weiss, wie ich es machen soll. Sind zwei Sorten von Daten: - quasi-permanente Daten, die an einem geografischen Objekt haengen sollten, die aber nur fuer einen ganz kleinen Kreis von Experten Bedeutung haben - temporaere Daten an geografischen Objekten, die zusaetzlich auch noch zeitlich befristete sind. Waere bequem, die einfach in die OSM Datenbank einzufuegen, aber wenn man es genau betrachtet, ist das nicht-akzeptabler Datenballast fuer fast alle anderen Benutzer. Ich glaube, dass der hier diskutierte Fall von derselben Art ist. 2014-11-11 16:35 GMT+01:00 Holger Jeromin mailgm...@katur.de: Manfred A. Reiter wrote on 11.11.2014 15:57: Am 11. November 2014 15:32 schrieb Holger Jeromin mailgm...@katur.de: Manfred A. Reiter wrote on 10.11.2014 01:32: Am 8. November 2014 16:46 schrieb Andreas Neumann andr-neum...@gmx.net Zitat: Das Ganze ist schwer zu verstehen, das weiß ich. Lass also die Einträge bitte beide bestehen, es ist wirklich das Beste in diesem Fall eine Adresse / Einrichtung eben doppelt zu haben. Diesen Ton halte ich für völlig unangemessen! Das Ganze ist schwer zu verstehen ... spinnt der? Vorsicht, das kann zwei Dinge bedeuten: Unser Setup ist leider nicht so flexibel wie wir gerne hätten, daher ist es von außen nicht so klar, warum wir das so gemacht haben. oder Das ist so super komplex, da sind Sie zu doof das zu verstehen Ich habe erstmal keine Veranlassung von letzterer Intention auszugeben. Bist Du wirklich der Meinung, dass bei ersterer Vermutung nicht auch zwei Zeilen zur Erläuterung möglich gewesen wären, statt Natürlich wäre es möglich oder sogar sinnvoll gewesen. Ich wollte nur sagen, dass die emotionale Ebene bei reinen Textmails zu einer unbekannten Person nur über mehr Text oder zum Beispiel Smilies transportiert wird. Bei einem Gespräch per Sprache oder sogar zusätzlichen Bild (face2face) fällt es viel einfacher die Intention herauszulesen. -- Grüße Holger ___ 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] Suche Ansprechpartner und Lösungsvorschlag (elotse)
Am 11. November 2014 16:35 schrieb Holger Jeromin mailgm...@katur.de: Manfred A. Reiter wrote on 11.11.2014 15:57: [...] Natürlich wäre es möglich oder sogar sinnvoll gewesen. Ich wollte nur sagen, dass die emotionale Ebene bei reinen Textmails zu einer unbekannten Person nur über mehr Text oder zum Beispiel Smilies transportiert wird. Bei einem Gespräch per Sprache oder sogar zusätzlichen Bild (face2face) fällt es viel einfacher die Intention herauszulesen. an dieser Stelle sind wir völlig einer Meinung. ;-) LG M. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neues Feature auf OSM: Changeset-Diskussion
Hi, Frederik Ramm schrieb: Bislang musste man solche Diskussionen immer in einem anderen Medium führen und zum jeweiligen Changeset linken; nun kann die Diskussion direkt beim Changeset erscheinen. Das ist sicherlich noch nicht perfekt und wird mit der Zeit noch reifen, aber ich finde es schonmal eine sehr gute Sache. mir gefällt das Feature auch. Ich erhoffe mir dadurch vor allem auch bei kontroversen Edits eine freundlichere Kritik (da sie dann ja öffentlich ist). Das ganze ist das Resultat eines Google Summer of Code-Projekts und wurde von Lukasz Gurdek, einem Studenten aus Polen, implementiert. Mentor in dem Projekt war Serge Wroclawski. Eine Kleinigkeit gibts aber, die ich derzeit doof finde: Man ist nur für die eigenen *neuen* Changesets registriert aber nicht für schon bestehende. Könnte man das noch ändern? An wen wende ich mich dafür am besten? Außerdem wäre allgemein noch ein Feed für Changesetkommentare in meiner Umgebung interessant. Ich will mich ja nicht für jeden Changeset in meiner Umgebung extra subscriben ;) https://blog.openstreetmap.org/2014/11/02/introducing-changeset-discussions/ Eine weitere Anwendung wäre übrigensnoch das konstruktive Kommentieren. Man kann z.B. auf ein detailierteres Taggingschema hinweisen oder nochmal nachfragen, ob es auf dem Spielplatz auch ein Rutsche gibt, auf dem Parkplatz einen Behindertenplatz gibt,... Gruß, Peda ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche Ansprechpartner und Lösungsvorschlag (elotse)
Am 11.11.2014 um 16:06 schrieb Andreas Neumann: Nutzer DD1GJ http://www.openstreetmap.org/user/DD1GJ hat soeben den von mir gelöschten Node in abgewandelter Form wieder hergestellt http://www.openstreetmap.org/changeset/26704923 Nun ist ebusiness als Wert beim Office-Tag eingefügt worden. Da es in der Wiki nicht definiert ist, werde ich dem Nutzer eine Frist setzen dies Nachzuholen (inkl. Diskussion mit der Community), ansonten werde ich den Tag wieder löschen. MfG Andreas Hallo Andreas, etliche Mitwirkende werden sich bei den obigen Zeilen das Schmunzeln nicht verkneifen können. Schau einfach mal auf den Domain-Namen meiner Mailadresse und wandle die Kleinbuchstaben in Großbuchstaben um ... Ich habe in der Zwischenzeit im mehreren Telefonaten und Mails den Lotsen die Meinung der Community kundgetan und bin seit heute auch mit demjenigen in Kontakt, der sich das Ganze ausgedacht hat. Mein Ziel ist es, den Lotsen ein communityverträgliches Tagging-Schema nahezulegen, mit dem Sie ihr Vorhaben verwirklichen können. In Richtung Ministerium bin ich noch ganz am Anfang. Insbesondere bestehe ich da auf eine Offenlegung der Förderrichtlinien des Projektes um zu sehen, ob da wirklich OSM seitens des Ministeriums verlangt wurde. http://osm.mapki.com/history/node.php?id=3132885744 Ich habe den Knoten auf Wunsch des Ilmenauer Projektbüros wiederhergestellt, aber dabei auch einige Fehler korrigiert und den hier beanstandeten Datenmüll mit den hier diskutierten eBusinesslotse-Tags weggelassen bzw. vernünftiges an die etablierten Tags gehängt. Der von Dir beanstandete ebusiness-Wert beim office-Tag war schon vorher da und ist angesichts der ca. 60 ebusiness=yes momentan von untergeordneter Bedeutung. Ich werde den Losten vorschlagen, über ein network=eBusiness-Lotse nachzudenken. Ich denke, beim network-Tag verhält es sich wie beim name-Tag, so dass wir hier nicht auch noch über die Namensgebung des Wertes diskutieren müssen. Meine Grundforderungen an die Lotsen ist die Verwendung der bereits etablierten Tags und der Verzicht auf die Eigenkreationen. Ein Projektbüro soll ruhig als eigenständiger Knoten getrennt von der Haupteinrichtung/Firma mit eigenen Kontaktdaten eingetragen werden. Bei http://www.openstreetmap.org/way/186275381 dürften sicherlich allen von uns die Haare zu Berge stehen. Der Dialog ist gerade in Gang gekommen und ich bin mit meinen Recherchen noch lange nicht fertig. Ich lese hier die Argumente und Vorschläge der anderen Mapper und lasse diese natürlich in meine Argumentation mit einfließen. Da ich die Angelegenheit ruhig, sachlich und nachhaltig regeln möchte, lasse ich mir natürlich von keiner Seite eine Frist setzen. Viele Grüße Joachim ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche Ansprechpartner und Lösungsvorschlag (elotse)
Hallo Joachim, On 12.11.2014 06:40, Joachim Kast wrote: Da ich die Angelegenheit ruhig, sachlich und nachhaltig regeln möchte, lasse ich mir natürlich von keiner Seite eine Frist setzen. ich habe dich ja nun auch schon persönlich getroffen und als ruhigen und sachlichen Menschen erlebt. Ich denke du wirst hier schon so vermitteln können dass wir eine Lösung haben bei der sowohl die Community und OSM als Ganzes als auch das Projektbüro zufrieden sind. Schließlich wollen wir ja alle, dass die OSM Daten auch verwendet werden. Ich habe nicht recherchiert wer dieser Andreas eigentlich ist, aber der Kommentar einen Tag zu löschen falls er nicht binnen Frist im Wiki dokumentiert (und vorher abgestimmt ist) zeigt doch ein größeres Defizit im Verständnis wie das Tagging bei OSM funktioniert. Lass dich davon nicht abschrecken. Du machst einen guten Job. Viele Grüße, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche Ansprechpartner und Lösungsvorschlag (elotse)
Hallo, Ich habe mit den Kollege -wie berichtet- ebenfalls schon Kontakt und habe bereits am 26.10 einen Ansatz in Richtung meshing of databases vorgeschlagen. Ich stelle Joachim den Mailwechsel zur Verfügung, denn von dem Network-Vorschlag halte ich persönlich für nicht optimal (Änderung eines Verwendungszweckes eines Tag's, müsste auch erst ausführlich diskutiert werden). Aber es ist doch erstaunlich, welche Emotionen entstehen. Bitte lasst uns bei einer sachlichen Diskussion bleiben! Übrigens ist meines Erachten der Meshing Ansatz langsam reif, produktiv getestet zu werden. Die Toolkette wie overpass-API läßt inzwischen eine zeitnahe Kontrolle des Datenbestandes zu, ohne das man 2GB komprimierte Daten für das Gebiet Deutschland von der Geofabrik runterladen muss. Aber das wäre ein separater Diskussionsstrang. Mit freundlichen Grüßen Georg V. (OSM=user_5359) ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] FOSSGIS 2015: Call for Papers FOSSGIS 2015 verlängert bis zum 29.11.2014
Hallo FOSSGIS-Aktive, OSM-Mitstreiter und alle Open Source GIS und Data Aktive, wir verlängern den Call for Papers für die #FOSSGIS2015 bis zum 29.11.2014. [http://www.fossgis.de/konferenz/2015/callforpapers/]. Direkt zur Abstrakteinreichung geht es hier: [http://pb.fossgis.de/submission/FOSSGIS2015]. Wir freuen uns auf Eure Beiträge, die benötigt werden, um auch für die FOSSGIS 2015 ein interessantes, vielseitiges und spannendes Programm für alle Teilnehmer zu erstellen. Wer mehr über Münster erfahren möchte, schaut in den nächsten Tagen auf der Konferenzhomepage vorbei. Natürlich dürft Ihr diese Nachricht in die entsprechenden Mailinglisten, in denen Ihr kommuniziert verteilen. Vielen Dank dafür. Die Aktivitäten und News zur FOSSGIS 2015 gibt es auch auf Twitter - [https://twitter.com/FOSSGIS2015]. Freundliche Grüße vom FOSSGIS-Orgateam ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] correzzione tunnel sotto i ponti
Sent: Tuesday, November 11, 2014 at 8:58 AM From: Volker Schmidt vosc...@gmail.com To: openstreetmap list - italiano talk-it@openstreetmap.org Subject: Re: [Talk-it] correzzione tunnel sotto i ponti Avevo detto che ci sono tanti casi di dubbio. Il problema reale è che pochissimi mappers sono ingegneri meccanici e sanno dire come è stato costruito un sottopassaggio quando lo vedono. Io parto dal concetto che se si tratta di qualcosa che assomiglia a un buco nella terra, è una galleria, se la costruzione è tutta da cemento o metallo o legno, è un ponte. Sì, così può essere più intuitivo. -- Matteo Quatrida GNU/Linux User #498939 OpenStreetMap Contributor since 2009 «Be GREEN and keep it on your SCREEN!» ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] mappare un frantoio
OK grazie ci metto sia man made, produce che shop Messaggio originale Da: cascaf...@gmail.com Data: 10/11/2014 22.03 A: openstreetmap list - italianotalk-it@openstreetmap.org Ogg: Re: [Talk-it] mappare un frantoio Il giorno 10 novembre 2014 16:22, Martin Koppenhoefer dieterdre...@gmail.com ha scritto: ci sono anche 9 http://taginfo.openstreetmap.org/tags/man_made=oil_mill di quali 8 con tag produce=olive_oil +1 Eccomi qua :-)https://www.openstreetmap.org/node/2520871571 ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] mappare un frantoio
2014-11-10 17:50 GMT+01:00 Volker Schmidt vosc...@gmail.com: Devo segnalare che c'è un possibile conflitto. Se una man_made=watermill produce olio di oliva, come lo tagghiamo? L'approccio corretto sarebbe di partire da man_made=mill con subtags produce mill_type ecc. Ma man_made=mill è poco usato +1, io andrei su lista tagging, è evidente che lì c'è ancora necessità di pensarci un attimo sopra e di rivedere possibilmente gli schemi attualmente in uso. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] correzzione tunnel sotto i ponti
2014-11-10 16:02 GMT+01:00 Matteo Quatrida matteo.quatr...@linuxmail.org: PS. Per favore, mandate mail in testo e non in HTML. Anche da Gmail è possibile ed è semplice da fare, pensavo di farlo, ti riferisci ad Aury? Io vedo nel mio header: From: Martin Koppenhoefer dieterdre...@gmail.com To: openstreetmap list - italiano talk-it@openstreetmap.org Content-Type: multipart/alternative; boundary=001a11c3c5e24da3440507823a7e --001a11c3c5e24da3440507823a7e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable è il multipart il problema? Non saprei come correggerlo, credo che sia dovuto al fatto che ho citato una mail in html? ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] correzzione tunnel sotto i ponti
2014-11-10 22:15 GMT+01:00 Matteo Quatrida matteo.quatr...@linuxmail.org: personalmente penso che tunnel debba essere usato solamente quando la «tecnica realizzativa» è uno scavo attraverso un paesaggio naturale intatto. ci sono definizioni diverse, la definizione che citi tu è sicuramente un metodo di costruzione per un tunnel, ma anche quando si scava dentro qualcosa che non è paesaggio naturale intatto ma fondo modificato dall'uomo penso che si tratta di un tunnel. Poi secondo svariate normative (esempio americane e tedesche, probabilmente anche italiane) si parla di un tunnel anche nel caso che viene scavato all'aperto (da sopra) e poi richiuso, quando la sua lunghezza supera x metri, dove x in Germania sarebbe 80m. Altre definizioni parlano della relazione delle dimensioni: più lungo che largo. (Non è male, è semplice da vedere / rilevare, e non chiede conoscenze particolari sulle normative di costruzione). ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Punto trigonometrico
2014-11-11 8:16 GMT+01:00 demon.box e.rossin...@alice.it: Lo posso anche mettere sullo stesso nodo della cima (natural=peak) se nella realtà è così? Oppure è sempre meglio distinguerlo? se coincidono tutti gli attributi lo puoi fare (esempio nome, altezza, ecc,) ma normalmente sarebbe più pulito crearne uno secondo (ho inventato la relazione node per questo scopo: https://wiki.openstreetmap.org/wiki/Relations/Proposed/Node Nei commenti c'è anche l'idea di una relazione attached_to che avrebbe senso in questo caso (non ce ne sta nemmeno un singolo uso se ho cercato bene: https://taginfo.openstreetmap.org/search?q=type%3Dattached_to ) ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] correzzione tunnel sotto i ponti
Sent: Tuesday, November 11, 2014 at 9:58 AM From: Martin Koppenhoefer dieterdre...@gmail.com Altre definizioni parlano della relazione delle dimensioni: più lungo che largo. (Non è male, è semplice da vedere / rilevare, e non chiede conoscenze particolari sulle normative di costruzione). ciao, Martin +1 Questa è sicuramente la migliore! -- Matteo Quatrida GNU/Linux User #498939 OpenStreetMap Contributor since 2009 «Be GREEN and keep it on your SCREEN!» ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] TRAVIC - Transit Visualization Client
2014-11-09 10:15 GMT+01:00 Maurizio Napolitano napoo...@gmail.com: Basta che chi sta dando a google metta tutto in OpenData Cmq su travic ci sono i dati del trentino, Piemonte e Roma si, Roma c'è ed è quasi più bella della verità ;-) Sono dati teorici, vero? Non tiene conto degli autobus partiti in ritardo, rimasti fermi per guasto, ecc.? Ho questa impressione, perché gli autobus sulla mappa sono distribuiti benissimi, mentre nella realtà occorrono hai 2 talvolta anche 3 autobus della stessa linea alla stessa fermata (o con 1 minuto di distanza), e poi per 20-30 minuti più nessuno ;-) ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] wami
Ciao, recentemente ho conosciuto i ragazzi di WAMI, una startup italiana che sta iniziando a lavorare con dati OSM. sono usciti con due prodotti: il primo è una API, molto simile ad overpass-api che permette di ottenere informazioni su POI prossimi ad una determinata coordinata http://map.wami.it/ l'altro prodotto, o meglio, famiglia di prodotti è una serie di applicativi mobile ios/android/html5. Si tratta di guide a città o regioni, la mappa è offline e viene renderizzata in real time all'interno del dispositivo (tipo mapnik), http://www.wami.it/wami-mobile-travel-guides/milano mi hanno chiesto un feedback sui loro prodotti, li trovate anche su twitter: https://twitter.com/wamiguides -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] ZTL e zona pedonale
2014-11-08 19:32 GMT+01:00 yahoo-pier_andreit pier_andr...@yahoo.it: come si mette una ZTL?? e una zona pedonale dove pero' ci possono andare pulman taxi residenti e commercianti e altre varie categorie poco chiare??? c'è questa proposta, usata finora 3 volte ;-) https://wiki.openstreetmap.org/wiki/Proposed_features/boundary%3Dlimited_traffic_zone poi questa, usata 51 volte https://wiki.openstreetmap.org/wiki/Proposed_features/boundary%3Dlow_emission_zone poi buondary=LEZ, usato 18 volte Poi c'è questo approccio di relazione: https://wiki.openstreetmap.org/wiki/LEZ usato 15 volte: http://taginfo.openstreetmap.org/search?q=type%3Dlez usato per il momento a Roma, per esempio: http://www.openstreetmap.org/relation/2573006 ma non mi piace perchè usa un'abbreviazione. Si può dire che non ha fatto botto ne anche questa proposta, soltanto 10 relazioni hanno quel tag secondo il wiki. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] fiumi o torrenti tombati
2014-11-09 19:46 GMT+01:00 Davide Mangraviti davide...@inwind.it: Il tag corretto da aggiungere alla parte tombata secondo me dovrebbe essere: tunnel = culvert Altre indicazioni? c'é anche culvert=yes come alternativa: http://taginfo.openstreetmap.org/keys/culvert Per il momento perde chiaramente: http://taginfo.openstreetmap.org/tags/tunnel=culvert ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] mappare casette di legno per la vendita di prodotti locali
Da evitare kiosk, il wikiesempio è sui fiori, ma facilmente estendibile ad altri prodotti: «Do not tag kiosks such as flower kiosks that do not sell the typical kiosk goods as shop=kiosk. Tag these with the type of goods they sell, such as shop=florist.» Un edificio (anche se è piccolo, anche se è di legno «building:material=wood», anche se sarà smontato tra poco) resta sempre un edificio con destinazione d'uso ben precisa, quindi senza dubbio building=retail. Nell'edificio si svolge attività commerciale (quindi shop=*) o attrattiva (amenity=*). Nel tuo caso il valore di opening_hours dovrebbe contenere almeno Apr-Oct off La sintassi completa per opening_hours è descritta qui https://wiki.openstreetmap.org/wiki/Key:opening_hours:specification Per essere sicuri di aver compreso correttamente la sintassi (all'inizio un po' ostica) puoi controllarla qui http://openingh.openstreetmap.de/evaluation_tool/ Inoltre valuta l'uso della key note. Per le informazioni temporanee mi sembra interessantissima questa proposta https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/temporary da adattare ai buildings/shops nel tuo caso. Il mio dubbio principale è che queste informazioni diventino *rapidamente* obsolete, quindi prima di mapparle mi chiederei SE vadano mappate, se sto mappando qualcosa *on_the_ground* (anche ad agosto?), se l'informazione che inserisco è *verificabile* da chiunque (anche ad agosto?), quale ragionevole certezza (verificabile?) ci sia che il prossimo anno non si debbano cambiare la metà di quelle informazioni, ... Forse OSM non è il posto giusto dove inserire mercati stagionali, forse è il caso di fondare OpenStreetMarkets, ... Buon mapping! Il 10 novembre 2014 23:17, Luca Delucchi lucadel...@gmail.com ha scritto: 2014-11-10 15:58 GMT+01:00 Matteo Quatrida matteo.quatr...@linuxmail.org: Ciao, ciao, premetto e mi scuso in anticipo, di non aver fatto grandi ricerche in merito, ma è un periodo in cui ho poco tempo libero. Vorrei segnalare la presenza sul marciapiede, di alcune vie di Trento, di «casette di legno» (probabilmente di proprietà del Comune di Trento), che vendono prodotti tipici (vin brulè, bombardino, castagne, ...) nel periodo invernale. Sono casette che restano montate dove sono da novembre a marzo circa. In particolare, quella, che ho provvisoriamente mappato come potevo, è gestita da un'azienda di un paese di una valle nei dintorni di Trento. [1] Ho dubbi su come definire l'attività, su come definire l'edificio provvisorio, su come definire la presenza temporalmente limitata e su come indicare l'operatore, visto che la sede dell'attività è altrove. io userei kiosk, e poi ci metti magari cuisine... Grazie a chi si prenderà la briga di illuminarmi. [1]: http://www.openstreetmap.org/node/3164166969#map=19/46.06682/11.12236 -- 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
Re: [Talk-it] wami
2014-11-11 11:09 GMT+01:00 Simone Cortesi sim...@cortesi.com: mi hanno chiesto un feedback sui loro prodotti, li trovate anche su twitter: https://twitter.com/wamiguides gli avevo scritto all'inizio di Luglio e c'era uno scambio di qualche mail, perché c'era un problema di attribuzione, hanno risolto nel frattempo? ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] wami
2014-11-11 12:01 GMT+01:00 Martin Koppenhoefer dieterdre...@gmail.com: 2014-11-11 11:09 GMT+01:00 Simone Cortesi sim...@cortesi.com: mi hanno chiesto un feedback sui loro prodotti, li trovate anche su twitter: https://twitter.com/wamiguides gli avevo scritto all'inizio di Luglio e c'era uno scambio di qualche mail, perché c'era un problema di attribuzione, hanno risolto nel frattempo? a me sembra tutto a posto, sia mobile che sul web. -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] mappare casette di legno per la vendita di prodotti locali
2014-11-11 11:47 GMT+01:00 Mauro Costantini maurocostantini1...@gmail.com: Un edificio (anche se è piccolo, anche se è di legno «building:material=wood», anche se sarà smontato tra poco) resta sempre un edificio con destinazione d'uso ben precisa, quindi senza dubbio building=retail. un kiosk è un building type ben definito, mentre building=retail è un tag molto generico e potrebbe essere tutto da http://www.innovaxis.com/images/omni-kiosk1-big1.jpg a http://www.archicentral.com/wp-content/images/selfridges_birmingham_01.jpg http://www.taz.de/uploads/images/624/kadewe_01.jpg io quei ultimi due taggherei come building=department_store Per la destinazione d'uso (se la vogliamo taggare) ci manca un tag. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] TRAVIC - Transit Visualization Client
Si, sono visualizzazioni basate sugli orari teorici. è stato chiesto di inserire i dati in tempo reale su travic ma dicono che sono in un formato non supportato. The real time data API is not GTFS-RT so it can not be included https://twitter.com/Janetovan/status/512980131200389120 Il 11/11/2014 10:51, Martin Koppenhoefer ha scritto: si, Roma c'è ed è quasi più bella della verità ;-) Sono dati teorici, vero? Non tiene conto degli autobus partiti in ritardo, rimasti fermi per guasto, ecc.? Ho questa impressione, perché gli autobus sulla mappa sono distribuiti benissimi, mentre nella realtà occorrono hai 2 talvolta anche 3 autobus della stessa linea alla stessa fermata (o con 1 minuto di distanza), e poi per 20-30 minuti più nessuno ;-) ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Import Civici Biella
Ciao a tutti, seguendo le import guidelines, con questa mail inizio il processo di discussione sull'importazione dei numeri civici di Biella messi a disposizione dal Comune. Il piano di dettaglio - che è oggetto di discussione - è descritto su questa pagina wiki: https://wiki.openstreetmap.org/wiki/Import/Catalogue/Address_import_for_Biella Il codice sorgente da usare l'ho già scritto ma necessita di un po' di pulizia prima di pubblicarlo. Per poter procedere alle successive fasi, che precedono l'import, bisogna che le comunità (quella Piemontese e quella Italiana) acconsentano a tale import. Ciao, Andrea ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Mappa delle disabilità
giusto per chiudere con l'argomento, ho fatto un mini tutorial per chi volesse replicarlo: http://www.piersoft.it/?p=297 Il giorno 10 novembre 2014 02:12, Germano Massullo germano.massu...@gmail.com ha scritto: I miei più grandi complimenti per la vostra nobile iniziativa. Per caso siete in contatto anche con http://www.informaticisenzafrontiere.org/ ? Potreste ottenere un aiuto in più per le vostre attività ___ 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] TRAVIC - Transit Visualization Client
Sent: Tuesday, November 11, 2014 at 10:51 AM From: Martin Koppenhoefer dieterdre...@gmail.com si, Roma c'è ed è quasi più bella della verità ;-) Sono dati teorici, vero? Non tiene conto degli autobus partiti in ritardo, rimasti fermi per guasto, ecc.? Ho questa impressione, perché gli autobus sulla mappa sono distribuiti benissimi, mentre nella realtà occorrono hai 2 talvolta anche 3 autobus della stessa linea alla stessa fermata (o con 1 minuto di distanza), e poi per 20-30 minuti più nessuno ;-) ciao, Martin___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it[https://lists.openstreetmap.org/listinfo/talk-it] Sono basati sulle timetables, se ho ben capito. -- Matteo Quatrida GNU/Linux User #498939 OpenStreetMap Contributor since 2009 «Be GREEN and keep it on your SCREEN!» ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Import Civici Biella
Eccellente inizio. Sono curioso per lo script python, magari potremmo usarlo per sistemare i nomi dei civici toscani e sardi. Il 11/nov/2014 12:29 Andrea Musuruane musur...@gmail.com ha scritto: Ciao a tutti, seguendo le import guidelines, con questa mail inizio il processo di discussione sull'importazione dei numeri civici di Biella messi a disposizione dal Comune. Il piano di dettaglio - che è oggetto di discussione - è descritto su questa pagina wiki: https://wiki.openstreetmap.org/wiki/Import/Catalogue/Address_import_for_Biella Il codice sorgente da usare l'ho già scritto ma necessita di un po' di pulizia prima di pubblicarlo. Per poter procedere alle successive fasi, che precedono l'import, bisogna che le comunità (quella Piemontese e quella Italiana) acconsentano a tale import. Ciao, Andrea ___ 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] Ruderi
Tralasciando il building=collapsed (che come già scritto non descrive una tipologia di edificio ma è stato introdotto solo nell'ambito delle crisi), questo mi pare uno dei rari casi in cui taginfo può aiutarci a capire come si comportano gli altri mappers nel resto del mondo. In ordine sono: il tag ruins=yes compare circa 17 mila volte associato ad un building=* il namespace abandoned: si trova 7 mila volte applicato a building; esistono ancora oltre 6 mila abandoned=yes associati a buildings (prima che venissero introdotti i namespace), totale oltre 15 mila. building:condition ha meno di mille usi con valori ben documentati nel wiki. Altri 8 mila con tre values good, average, poor scarsamente documentati e usati in pochissime zone al mondo; building=ruins 3 mila building=ruin mille. La mia scelta personale privilegia l'uso dei namespaces. E ora perdonatemi il paragrafo filosofico ... si mappa per avere dati veri, aggiornati e verificabili; chi/come deciderà di usarli non è affare di osm. C'è (ovviamente) una visualizzazione di default, ma chiunque è incoraggiato a usare i dati anche in altri modi: OpenMtbMap che tu citi è un buon esempio, una loro scelta cosa visualizzare e cosa no (naturalmente sceglieranno le priorità in base all'utilizzo, difficilmente implementeranno qualcosa che ha 2 occorrenze al mondo). Allo stesso modo dobbiamo considerare gli editor: uno dei tanti modi di fruire (e modificare) i dati del database di osm; gli editor sono tanti, ogni mapper sceglierà quello che gli va meglio per fare determinate modifiche. La scelta del tag deve dipendere dal suo significato (possibilmente documentato sul wiki), non dalla facilità di editing con un determinato editor. Buon mapping! ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Import Civici Biella
Ottima wiki, asciutta ed ordinata. Segnalo in talk-it-fvg che abbiamo l'import regionale in corso. Il giorno 11 novembre 2014 12:28, Andrea Musuruane musur...@gmail.com ha scritto: Ciao a tutti, seguendo le import guidelines, con questa mail inizio il processo di discussione sull'importazione dei numeri civici di Biella messi a disposizione dal Comune. Il piano di dettaglio - che è oggetto di discussione - è descritto su questa pagina wiki: https://wiki.openstreetmap.org/wiki/Import/Catalogue/Address_import_for_Biella Il codice sorgente da usare l'ho già scritto ma necessita di un po' di pulizia prima di pubblicarlo. Per poter procedere alle successive fasi, che precedono l'import, bisogna che le comunità (quella Piemontese e quella Italiana) acconsentano a tale import. Ciao, Andrea ___ 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] Ruderi
2014-11-11 13:25 GMT+01:00 Mauro Costantini maurocostantini1...@gmail.com: La mia scelta personale privilegia l'uso dei namespaces. +1 è la soluzione più matura che riesce al meglio di evitare interpretazioni sbagliati e che si integra migliormente nel resto del sistema. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Import Civici Biella
2014-11-11 12:28 GMT+01:00 Andrea Musuruane musur...@gmail.com: Ciao a tutti, seguendo le import guidelines, con questa mail inizio il processo di discussione sull'importazione dei numeri civici di Biella messi a disposizione dal Comune. Il piano di dettaglio - che è oggetto di discussione - è descritto su questa pagina wiki: https://wiki.openstreetmap.org/wiki/Import/Catalogue/Address_import_for_Biella con mia stessa colpevolezza segnalo che dovremmo agigungere le fonti qui http://www.openstreetmap.org/copyright e qui http://wiki.openstreetmap.org/wiki/Contributors#Italy -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Import Civici Biella
2014-11-11 12:28 GMT+01:00 Andrea Musuruane musur...@gmail.com: Per poter procedere alle successive fasi, che precedono l'import, bisogna che le comunità (quella Piemontese e quella Italiana) acconsentano a tale import. Dovresti anche scrivere alla lista imports, se non l'hai già fatto. (dal punto 2) ...You can do this with an email to (at a minimum) impo...@openstreetmap.org, talk-(your country)@openstreetmap.org, and the OSM group specific to the the area directly impacted by the import. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Import Civici Biella
2014-11-11 14:49 GMT+01:00 Martin Koppenhoefer dieterdre...@gmail.com: 2014-11-11 12:28 GMT+01:00 Andrea Musuruane musur...@gmail.com: Per poter procedere alle successive fasi, che precedono l'import, bisogna che le comunità (quella Piemontese e quella Italiana) acconsentano a tale import. Dovresti anche scrivere alla lista imports, se non l'hai già fatto. (dal punto 2) ...You can do this with an email to (at a minimum) impo...@openstreetmap.org, talk-(your country)@openstreetmap.org, and the OSM group specific to the the area directly impacted by the import. Yes ma lo faccio dopo aver raggiunto un minimo di consenso sulla proposta sulle 2 ML locali. Ciao, Andrea ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Import Civici Biella
Ciao. Ho letto la pagina [1], ed ho visto che alla fine i tag sarebbero: addr:housenumber addr:street addr:postcode addr:city addr:country Sarebbe però più pulito avere solo addr:housenumber, ed usare la relazione associatedStreet per collegare il nodo alla sua strada. Gli altri tag addr:postcode, addr:city, addr:country andrebbero omessi perché ricavabili dai confini comunali e statali. Questo è l'approccio che uso io quando mappo i civici e che se non erro è considerato più efficiente. Ora capisco che potrebbe essere un problema in un colpo solo creare tutte le relazioni, anche perché come leggo in [1], potrebbero esserci dei nomi di vie diversi da quelli già presenti. Si potrebbe allora intanto importare addr:street ed in un secondo momento andare a creare le relazioni manualmente, filtrando tutti i nodi di una street ad esempio con un semplice ricerca in JOSM. In ogni caso tralascerei gli altri tag ridondanti addr:postcode, addr:city ed addr:country. Che ne pensate? Alberto [1] https://wiki.openstreetmap.org/wiki/Import/Catalogue/Address_import_for_Biella --- Questa e-mail è priva di virus e malware perché è attiva la protezione avast! Antivirus. http://www.avast.com ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Import Civici Biella
Sui nodi come parti di una relazione street ne era parlato in qs giorni. Se non sbaglio si preferisce il metodo triviale, anche se ridondante per non confondere gli utenti neofiti che volessero editare. -- cascafico.altervista.org twitter.com/cascafico Syncthing Node ID 2M2D4D6-Q7QSYGE-VGLD4YO-KR62AOJ-F6MUSUA-AQRF27C-XVQP63G-4ADMFAA Il 11/nov/2014 15:47 Alberto albertoferra...@fastwebnet.it ha scritto: Ciao. Ho letto la pagina [1], ed ho visto che alla fine i tag sarebbero: addr:housenumber addr:street addr:postcode addr:city addr:country Sarebbe però più pulito avere solo addr:housenumber, ed usare la relazione associatedStreet per collegare il nodo alla sua strada. Gli altri tag addr:postcode, addr:city, addr:country andrebbero omessi perché ricavabili dai confini comunali e statali. Questo è l'approccio che uso io quando mappo i civici e che se non erro è considerato più efficiente. Ora capisco che potrebbe essere un problema in un colpo solo creare tutte le relazioni, anche perché come leggo in [1], potrebbero esserci dei nomi di vie diversi da quelli già presenti. Si potrebbe allora intanto importare addr:street ed in un secondo momento andare a creare le relazioni manualmente, filtrando tutti i nodi di una street ad esempio con un semplice ricerca in JOSM. In ogni caso tralascerei gli altri tag ridondanti addr:postcode, addr:city ed addr:country. Che ne pensate? Alberto [1] https://wiki.openstreetmap.org/wiki/Import/Catalogue/Address_import_for_Biella --- Questa e-mail è priva di virus e malware perché è attiva la protezione avast! Antivirus. http://www.avast.com ___ 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] Import Civici Biella
Ciao Alberto, 2014-11-11 15:47 GMT+0100 Alberto albertoferra...@fastwebnet.it: Ciao. Ho letto la pagina [1], ed ho visto che alla fine i tag sarebbero: addr:housenumber addr:street addr:postcode addr:city addr:country Sarebbe però più pulito avere solo addr:housenumber, ed usare la relazione associatedStreet per collegare il nodo alla sua strada. Gli altri tag addr:postcode, addr:city, addr:country andrebbero omessi perché ricavabili dai confini comunali e statali. Questo è l'approccio che uso io quando mappo i civici e che se non erro è considerato più efficiente. Ora capisco che potrebbe essere un problema in un colpo solo creare tutte le relazioni, anche perché come leggo in [1], potrebbero esserci dei nomi di vie diversi da quelli già presenti. Si potrebbe allora intanto importare addr:street ed in un secondo momento andare a creare le relazioni manualmente, filtrando tutti i nodi di una street ad esempio con un semplice ricerca in JOSM. In ogni caso tralascerei gli altri tag ridondanti addr:postcode, addr:city ed addr:country. Che ne pensate? In questo ultimo periodo ho studiato vari import di numeri civici fatti in precedenza. Nessuno (dico proprio nessuno) di questi ha importato i civici usando la relazione associatedStreet. Sull'uso di questa relazione c'è stata una discussione qualche giorno fa: https://lists.openstreetmap.org/pipermail/talk-it/2014-November/045351.html Non c'era un reale accordo sul fatto che fosse più efficiente o pulito. Sembra più una questione di preferenze personali - con entrambi i metodi accettati. Ciao, Andrea ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Import Civici Biella
Andrea Musuruane wrote Per poter procedere alle successive fasi, che precedono l'import, bisogna che le comunità (quella Piemontese e quella Italiana) acconsentano a tale import. Mi fa molto piacere questa iniziativa, inoltre il wiki per l'import e' fatto molto bene. Solo 2 puntualizzazioni: - non sarebbe il caso di aggiornare il wiki It:Key:name per adeguarlo un po' alle ultime convenzioni ISTAT (in vista anche di altre importazioni? - non sarebbe il caso di chiedere al Comune di Biella se hanno pronto un aggiornamento dei dati (magari gia' adeguati alle convenzioni ISTAT), considerato che quelli online sono datati 09/01/2014 e l'aggiornamento dovrebbe essere annuale (quindi quasi pronto)? Saluti. -- Marco_T -- View this message in context: http://gis.19327.n5.nabble.com/Import-Civici-Biella-tp5823953p5823999.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] Import Civici Biella
ciao, Volevo dirti che la wiki è ottima e molto ben fatta. Complimenti! segnalo solamente che in OSM attribution si linka un Contributors#Biella che non esiste...consiglio di mettere la voce relativa a Biella sotto Contributors#Italy come già fatto per la città di Torino, Palermo e Venezia (sbaglio o ne mancano alcuni? sono certo altre città italiane siano frutto almeno in parte di un import) ;-) ciao, Aury88 - Ciao, Aury -- View this message in context: http://gis.19327.n5.nabble.com/Import-Civici-Biella-tp5823953p5824002.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] Import Civici Biella
2014-11-11 19:04 GMT+01:00 Marco_T toto...@libero.it: Andrea Musuruane wrote Per poter procedere alle successive fasi, che precedono l'import, bisogna che le comunità (quella Piemontese e quella Italiana) acconsentano a tale import. Mi fa molto piacere questa iniziativa, inoltre il wiki per l'import e' fatto molto bene. Solo 2 puntualizzazioni: - non sarebbe il caso di aggiornare il wiki It:Key:name per adeguarlo un po' alle ultime convenzioni ISTAT (in vista anche di altre importazioni? Concordo ma lascio la palla a chi le ha studiate meglio di me. - non sarebbe il caso di chiedere al Comune di Biella se hanno pronto un aggiornamento dei dati (magari gia' adeguati alle convenzioni ISTAT), considerato che quelli online sono datati 09/01/2014 e l'aggiornamento dovrebbe essere annuale (quindi quasi pronto)? Io direi di iniziare con quello che abbiamo dato che migliora notevolmente la situazione in OSM e permette tutta una serie di lavori a valle come l'immissione dei nomi nelle strade che ne sono prive o l'inserimento di strade mancanti. Una volta che ci sarà un update, capiremo come fare il diff. Ciao, Andrea ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Import Civici Biella
2014-11-11 19:23 GMT+01:00 Aury88 spacedrive...@gmail.com: ciao, Volevo dirti che la wiki è ottima e molto ben fatta. Complimenti! segnalo solamente che in OSM attribution si linka un Contributors#Biella che non esiste...consiglio di mettere la voce relativa a Biella sotto Contributors#Italy come già fatto per la città di Torino, Palermo e Venezia L'intenzione è questa. Il link non esiste ancora perché l'import non è ancora stato fatto. Ciao, Andrea ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Import Civici Biella
Ero rimasto a questo schema [1], che dice Instead of using the addr:street tag, it's also possible to use relations to provide a connection between housenumber and street. Those are more easy and less error-prone to evaluate in software.. Io le relazioni le trovo più comode da aggiornare, ad es. con JOSM scarico unintera strada ed i civici in un attimo se cè la relazione, altrimenti devo scaricare unarea molto più vasta e poi filtrare quello che cerco. Tra laltro cè anche una proposta di inserire i marciapiedi mappati come way separate in associatedStreet [2]. In questo caso le relazioni le creerei in un secondo tempo, dopo limport. Però al di là della scelta tra relazione o addr:street, su cui ci sono opinioni diverse, che ne pensate di omettere i tag addr:postcode, addr:city, addr:country? [1] http://wiki.openstreetmap.org/wiki/Karlsruhe_Schema [2] http://wiki.openstreetmap.org/wiki/Talk:Relation:associatedStreet Alberto In questo ultimo periodo ho studiato vari import di numeri civici fatti in precedenza. Nessuno (dico proprio nessuno) di questi ha importato i civici usando la relazione associatedStreet. Sull'uso di questa relazione c'è stata una discussione qualche giorno fa: https://lists.openstreetmap.org/pipermail/talk-it/2014-November/045351.html Non c'era un reale accordo sul fatto che fosse più efficiente o pulito. Sembra più una questione di preferenze personali - con entrambi i metodi accettati. Ciao, Andrea --- Questa e-mail è priva di virus e malware perché è attiva la protezione avast! Antivirus. http://www.avast.com ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-dk] Vandre- og cykelruter på mobilen
En god nyhed: Den nyeste version af OsmAnd+ (1.9.2g) kan vise cykel- og vandreruter på downloadede kort. Sæt hak ud for Kort / Menu / Konfigurer kort / Vis cykelruter hhv. Kort / Menu / Konfigurer kort / Vandresymbol overlejring (sic!) Under de første afprøvninger syntes jeg, at der manglede nogle vandreruter, og det viste sig at være dem, der er tagget med route=foot, som jo ellers er OK at bruge, så der er stadig plads til forbedringer. Men for os, der ikke altid har en dataforbindelse (læs: ikke vil betale tysk overpris) så vi kan tjekke lonvia på nettet, er det et godt initiativ. /sba-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Vandre- og cykelruter på mobilen
Det ser helt godt ud. Prøv også at lege med Kort / Menu Konfigurer kort / Optegningsmåde / Bil|Cykel|Fodgænger. Vælger man Cykel, markeres veje med cykelstier med en blå stiplet linje. Dette kan ligeledes forbedres (f.eks. giver cykelvisning af oneway=yes;cycleway=opposite en ensrettet cykelsti i bilernes ensretning - og Bicycle=segregated indtegnes slet ikke på kortet! Men det er ellers en rigtig god start! Den 11. nov. 2014 kl. 14.57 skrev Sonny B. Andersen s...@bukhmark.dk: En god nyhed: Den nyeste version af *OsmAnd+* (1.9.2g) kan vise cykel- og vandreruter på downloadede kort. Sæt hak ud for Kort / Menu / Konfigurer kort / Vis cykelruter hhv. Kort / Menu / Konfigurer kort / Vandresymbol overlejring (sic!) Under de første afprøvninger syntes jeg, at der manglede nogle vandreruter, og det viste sig at være dem, der er tagget med route=foot, som jo ellers er OK at bruge, så der er stadig plads til forbedringer. Men for os, der ikke altid har en dataforbindelse (læs: ikke vil betale tysk overpris) så vi kan tjekke lonvia på nettet, er det et godt initiativ. /sba-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk -- -- Civilingeniør ph.d. Claus Hindsgaul Studsbøl Alle 81 DK-2770 Kastrup ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-es] #224 semanario OSM ya en español
Buenas, Ya que estamos comentando el tema, indicaros que en el feed RSS en español sigue diciendo «Disculpa, pero esta entrada está disponible sólo en Deutsch y English.» Pero si entras en la web si que sale en español. Un saludo Atentamente, Suárez 2014-11-10 18:58 GMT+01:00 Johnattan Rupire jarja...@riseup.net: Hola! sin duda es un esfuerzo más que importante! lo movemos por algunos canales en Perú. saludos! El 10/11/14 a las 01:43, Gus Urban escribió: Muchas gracias Carlos Un saludo gustavo El 9 de noviembre de 2014, 20:25, Alejandro S. alejandro...@gmail.com escribió: Hola, Creo que el weeklyosm es una forma útil de estar al tanto de las noticias relacionadas con OSM, así que agradezco su traducción. Saludos, Alejandro SUÁREZ CEBRIÁN El 09/11/2014 22:21, Manfred A. Reiter ma.rei...@gmail.com escribió: Olá Javier, muchass gracias, para decir gracias para Carlos. Me permite una pregunta: ¿Piensas que es necessario/útil/deseable para la communidad española de OSM, que Carlos Cie. continuaran haciendo el esfuerzo de traducir el weekyOSM al español? Lo pregunto porque Ud. es la única persona que ha respondido a las traducciones (afais) de Carlos, Susana y todos los otros. ;-) Qué piensa usted: ¿cuál es la opinión de la mayoría silenciosa? Manfred from team weeklyOSM 2014-11-09 21:08 GMT+01:00 Javier Sánchez javiers...@gmail.com: Gracias Carlos El 9 de noviembre de 2014, 18:49, Carlos Alonso car...@weeklyosm.eu escribió: Hola El semanario #224 de weeklyosm, el sumario de todo lo que está ocurriendo en mundo OSM está en linea en español http:/www.weeklyosm.eu/?lang=es Disfrutadlo!!! ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es -- ## Manfred Reiter - - ## A. Because it breaks the logical sequence of discussion ## Q. Why is top posting bad? ## Please avoid sending me Word or PowerPoint attachments. ## See: http://www.gnu.org/philosophy/no-word-attachments.html ## INGOTs Assessor Trainer ## (International Grades in Open Technologies) ## www.theingots.org ## www.igab-saar.de - Brückendemo 2007 - 4500 Menschen ## 16.02.2008 - Aktionstag Saarlouis - 7.000 Menschen ## 23.02.2008 - an der Katastrophe vorbeigeschrammt - 60.000 Menschen ## 24.02.2008 - Demo Saarwellingen - 6.000 Menschen - Der Schlossplatz ist zu klein ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-at] Objekte mit start_date/end_date
On Mon, Nov 10, 2014 at 10:34:39PM +0100, Friedrich Volkmann wrote: On 10.11.2014 19:13, Stephan Bösch-Plepelits wrote: Nun, ich stimme zu, dass es trivial ist. Das heisst aber noch nicht, dass es auch getan wird. Nur als Beispiel, openstreetmap-carto, der Standardstil der OpenStreetMap, berücksichtigt start_date und end_date nicht. Wir können ein Ticket erstellen. halte start_date/end_date für nicht ideal. Ein node/way kann mehrere tags haben, dann ist nicht klar worauf sich start_date/end_date beziehen sollen. Schon http://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts gesehen? Mir gefällt eigentlich das tag:year-year Tagging ganz gut wobei ich year etwas allgemeiner mit Datum ersetzen würde. http://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts#Related_concepts Richard ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Objekte mit start_date/end_date
On 10.11.14 19:13, Stephan Bösch-Plepelits wrote: Nun, man könnte analog etwas wie bei Straßen machen. Dort ist ja während der Bauzeit highway=construction, construction=primary eingetragen. Nach Eröffnung wird das dann umgetaggt. Also vielleicht boundary=construction, construction=administrative??? Ich hatte das schon mal bei anderer Gelegenheit geschrieben: Es ist grundsätzlich NICHT sinnvoll, dass ein zweiter Tag die Beutung des ursprünglichen Tags umdreht, verändert, einschränkt, etc. Das war auf bei highway=primary, construction=yes das Problem, weshalb die jetzige Variante mit highway=construction, construction=primary noch die beste ist. Das ist auch ganz nachvollziehbar: Wenn ich eine Overpass-Query nach amenity=restaurant mache, dann will ich alle Restaurants. Und zwar die jetzt gültigen. Alles was vielleicht früher mal eins war, sollte jetzt sowas wie former:amenity=restaurant sein. So könnte man das auch bei den Admin-Boundaries lösen: alles, was jetzt gültige Grenze ist, ist boundary=administrative, alles, was früher mal war, former:boundary=administrative. Das Verändern des Keys hat übrigens Vorteile gegenüber einem Verändern der Value (siehe Beispiel highway=construction): Hieße der Key construction:highway=primary, würden bei der Query nach highway wirklich nur die jetzt gültigen Wege rausfallen, nicht eben auch die in Bau befindlichen oder gar die geplanten. Detto fallen bei amenity alle die ehemaligen POIs raus, die jetzt former:amenity sind. Macht Sinn, ist IMO die verträglichste Methode, nicht irgendjemand anderes Code zu brechen. /al ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Objekte mit start_date/end_date
Hi! Nichtsdestotrotz stehen jetzt gerade eben die tags start_date= und end_date= im admin_level=8 der Daten in Österreich. Prinzipiell find ich die Idee ja gut .. aber ich wäre ohne Stephan nicht auf die Idee gekommen und hab mich immer gefragt wieso da grad alles (also einiges) doppelt ausgespuckt wird (beim Checken auf Überlappungen im GIS). Gerade date wirft bei mir aber die Frage auf welches Format? Immerhin wird in verschiedenen Ländern das Datum auch unterschiedlich geschrieben. In Österreich steht es gerade als 2014-12-31 drinnen, was jetzt eher einer international Einheitlichen Schreibweise entspricht (zumindest ich würde als Österreicher das Datum andersrum schreiben). Mit dem Wissen das so etwas da ist ist für mich das Problem ja nun gelöst, aber ob und vor allem wie das richtig eingetragen gehört scheint ja noch nicht komplett geklärt zu sein. Danke für all die Info schon mal Liebe Grüße Werner 2014-11-11 13:13 GMT+01:00 Andreas Labres l...@lab.at: On 10.11.14 19:13, Stephan Bösch-Plepelits wrote: Nun, man könnte analog etwas wie bei Straßen machen. Dort ist ja während der Bauzeit highway=construction, construction=primary eingetragen. Nach Eröffnung wird das dann umgetaggt. Also vielleicht boundary=construction, construction=administrative??? Ich hatte das schon mal bei anderer Gelegenheit geschrieben: Es ist grundsätzlich NICHT sinnvoll, dass ein zweiter Tag die Beutung des ursprünglichen Tags umdreht, verändert, einschränkt, etc. Das war auf bei highway=primary, construction=yes das Problem, weshalb die jetzige Variante mit highway=construction, construction=primary noch die beste ist. Das ist auch ganz nachvollziehbar: Wenn ich eine Overpass-Query nach amenity=restaurant mache, dann will ich alle Restaurants. Und zwar die jetzt gültigen. Alles was vielleicht früher mal eins war, sollte jetzt sowas wie former:amenity=restaurant sein. So könnte man das auch bei den Admin-Boundaries lösen: alles, was jetzt gültige Grenze ist, ist boundary=administrative, alles, was früher mal war, former:boundary=administrative. Das Verändern des Keys hat übrigens Vorteile gegenüber einem Verändern der Value (siehe Beispiel highway=construction): Hieße der Key construction:highway=primary, würden bei der Query nach highway wirklich nur die jetzt gültigen Wege rausfallen, nicht eben auch die in Bau befindlichen oder gar die geplanten. Detto fallen bei amenity alle die ehemaligen POIs raus, die jetzt former:amenity sind. Macht Sinn, ist IMO die verträglichste Methode, nicht irgendjemand anderes Code zu brechen. /al ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Objekte mit start_date/end_date
On 11.11.14 13:34, Werner Macho wrote: Nichtsdestotrotz stehen jetzt gerade eben die tags start_date= und end_date= im admin_level=8 der Daten in Österreich. Man hätte die zukünftigen mit future:boundary taggen können, vor allem sollte man aber zu Sylvester jene http://overpass-turbo.eu/s/5SQ rel(area.a)[boundary=administrative][end_date=2014-12-31]; auf former:boundary umtaggen. Gerade date wirft bei mir aber die Frage auf welches Format? http://wiki.openstreetmap.org/wiki/Key:start_date oder -mmoder -mm-dd oder div. Approximations sind definiert. /al ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] in Austria, good experience - thank you!
On Mon Nov 10 2014 at 16:45:17 Stefan Tiran stefan.ti...@student.tugraz.at wrote: [1] I assume, it is mostly people who see the world only through the front shield of their car. I think this argument goes both ways, it all comes down to the level of abstraction you are going to apply. We usually also don't map every lane as single way, we consider them all as part of the street as well as a sidewalk is part of the street - I'm walking down Favoritenstraße and not a footway that happens to be next to Favoritenstraße (and to use it for routing some sort of preprocessing is needed any way). Having said that, I'm with you that deleting them is still vandalism. ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Objekte mit start_date/end_date
On 11.11.2014 13:13, Andreas Labres wrote: Ich hatte das schon mal bei anderer Gelegenheit geschrieben: Es ist grundsätzlich NICHT sinnvoll, dass ein zweiter Tag die Beutung des ursprünglichen Tags umdreht, verändert, einschränkt, etc. Das war auf bei highway=primary, construction=yes das Problem, weshalb die jetzige Variante mit highway=construction, construction=primary noch die beste ist. Ich sehe das nicht so, dass start_date und end_date die *Bedeutung* verändern, sondern sie bringen nur eine vierte Dimension (Zeitachse) in OSM ein. Ob wir diese überhaupt haben wollen, ist eine andere Frage. Das ist auch ganz nachvollziehbar: Wenn ich eine Overpass-Query nach amenity=restaurant mache, dann will ich alle Restaurants. Und zwar die jetzt gültigen. Alles was vielleicht früher mal eins war, sollte jetzt sowas wie former:amenity=restaurant sein. So könnte man das auch bei den Admin-Boundaries lösen: alles, was jetzt gültige Grenze ist, ist boundary=administrative, alles, was früher mal war, former:boundary=administrative. Damit fehlt aber die Information, wann das existiert hat. Mit der Information alleine, dass es irgendwann existiert hat. lässt sich nicht wirklich was anfangen. Besser entweder ordentlich (mit Datum) oder gar nicht in der Datenbank halten, sonst ist es nur Datenmüll. Die Key-Prefixes construction: und former: erinnern mich an disused:, welches irgendwo im Wiki dokumentiert ist, aber von niemandem verwendet wird. Ich verwende nur disused=yes. Während disused:*=* dazu dient, etwas vor allen Anwendungen zu verstecken, will ich mit disused=yes nämlich erreichen, dass Anwendungen die Objekte sehr wohl noch sehen und nur anders darstellen, z.B. ausgegraut oder als Pfad statt als Track. Wenn ich will, dass Anwendungen etwas komplett ignorieren, dann lösche ich es ganz raus. Dafür brauche ich kein Tag wie disused, former oder construction. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Objekte mit start_date/end_date
On 11/11/2014 02:40 PM, Friedrich Volkmann wrote: On 11.11.2014 13:13, Andreas Labres wrote: Ich hatte das schon mal bei anderer Gelegenheit geschrieben: Es ist grundsätzlich NICHT sinnvoll, dass ein zweiter Tag die Beutung des ursprünglichen Tags umdreht, verändert, einschränkt, etc. Das war auf bei highway=primary, construction=yes das Problem, weshalb die jetzige Variante mit highway=construction, construction=primary noch die beste ist. Ich sehe das nicht so, dass start_date und end_date die *Bedeutung* verändern, sondern sie bringen nur eine vierte Dimension (Zeitachse) in OSM ein. Ob wir diese überhaupt haben wollen, ist eine andere Frage. Mit der vierten Dimension geb ich dir Recht, aber für mich lautet die Antwort spontan eher nein. Also ganz sicher nicht wenn das heißt, dass jeder, der die Daten verwenden will sich selbst um das Auswerten dieser vierten Dimension in all ihren Ausformungen (Formate, Zeitzonen, Sommerzeiten, etc.) kümmern muss. D.h. natürlich nicht, dass opening_hours oder so nicht in OSM sein sollten, denn die spezifizieren ja nur Eigenschaften eines konstant vorhandenen Objekts. Wenn ich aber an jedem Objekt mit einer Zeitinformation rechnen muss ab denen es nicht mehr existiert oder erst existieren wird, dann macht das die Auswertung deutlich komplizierter. Nicht unlösbar, aber imo absolut unnötig kompliziert. Wenn aber die Mapper das Gefühl haben, dass sowas wichtig ist, und sie unbedingt solche Zeiten eintragen wollen, dann sollte das imo in der API gelöst werden, so dass ich dann sagen kann, ich möchte aktuelle Daten zum Zeitpunkt t oder von mir aus in der Zeitspanne t+d haben. Ich persönlich verwend nur end_date und das nur auf Baustellen, die ich von name=Baustelle (mit allen möglichen wichtigen und vor allem unwichtigen Zusatzinfos) umgetagged hab und da seh ich das Datum eher als Note für andere Mapper. Noch dazu wo die Daten auf den Baustellenschildern ohnehin selten eingehalten werden, wenn die Baustelle nur groß genug ist. Imo sollte es für ein Crowdsourcing Projekt möglich sein Änderungen halbwegs zeitnah einzupflegen. Wenn das nicht passiert, dann war's wohl noch keinem wichtig genug, was eigentlich ein ganz guter Filter ist. Das ist auch ganz nachvollziehbar: Wenn ich eine Overpass-Query nach amenity=restaurant mache, dann will ich alle Restaurants. Und zwar die jetzt gültigen. Alles was vielleicht früher mal eins war, sollte jetzt sowas wie former:amenity=restaurant sein. Damit fehlt aber die Information, wann das existiert hat. Mit der Information alleine, dass es irgendwann existiert hat. lässt sich nicht wirklich was anfangen. Besser entweder ordentlich (mit Datum) oder gar nicht in der Datenbank halten, sonst ist es nur Datenmüll. Die Information ist ungefähr im Changeset enthalten. Wenn das nicht genau genug ist, dann kann man es auch an das Objekt selbst taggen, aber wenn man es zusätzlich zum former: Prefix tagged, dann ist allen geholfen. Denen, die nur nach aktuell gültigen Objekten suchen und denen, die ganz exakt wissen wollen, ab welchem Zeitpunkt die Daten veraltet waren. Aber eigentlich denk ich sollte alles in der DB sein was aktuell ist und dann geändert werden, wenn es sich geändert hat. Ganz ohne die Verrenkungen um alle möglichen Zustände seit es OSM gibt (oder gar noch viel länger) zu erfassen. Wer das braucht sollte die History auswerten. Norbert ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Objekte mit start_date/end_date
mh. also ich habe das bis jetzt so verstanden: start_date ist das baujahr, das zB auf brücken, häusern, marterln usw ja öfter anschrieben ist. liegt üblicherweise in der vergangenheit und ist eine info, die nur ausgewertet werden wird, wenn es jemand drauf anlegt. besonders dadurch interessant, da das meiste was gemappt wird ja schon um einiges länger existiert als die osmap. end_date ist das voraussichtliche ablaufdatum, so wie schon erwähnt bei baustellen und ähnlichem. könnte ausgewertet werden, aber sollte es eigentlich auch nicht. weil wenns nicht mehr da ist, wirds gelöscht bis auf den eventuell sinnvollen info-node. wer altdaten braucht, sollte im archiv wühlen. oder lieg ich da falsch? das bei den gemeindegrenzen diese beide nutzungen sich überschneiden und noch dazu der übergang der realität von einer sekunde auf die andere stattfindet ist aus meiner sicht ein *grenz*fall, den man eigentlich gemütlich grenzfall lassen sein kann. der wird in dem moment aufgelöst wenn sich am 1.1. der erste mapper daran erinnert, dass es ja jetzt komplett andere grenzen gibt und schnell eine wohlüberlegte query auf boundaries mit end_dates loslassen kann und dann ein paar veraltete relationen löscht bevor noch ein armer steierischer mensch an der falschen stelle mit seinem reisepass steht und nirgends einen grenzer sieht und dann in seinem restrausch von sylvester total verzweifelt und nicht mehr weiss was er machen soll. ;) grüsse, grubernd ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] JOSM-Workshop: Interesse?
Hallo, Am letzten Grazer Stammtisch haben einige Leute Interesse an einem JOSM-Workshop gezeigt. Ich würde mich gerne bereiterklären einen zu halten, wenn sich mindestens 3 Leute finden. Als Ort würde ich das Spektral¹ in Graz vorschlagen (sofern zu dem Termin frei), es ist gemütlich und es gibt dort eine Küche, Strom sowie WLAN. Ich hab' mal ein dudle² angelegt. Ich bitte alle, die Interesse an einem kostenlosen JOSM-Workshop haben (Anfänger oder Fortgeschrittene, ganz gleich - mach ich je nach Bedarf) sich dort einzutragen. [1] https://www.openstreetmap.org/node/2510218855 [2] https://dudle.inf.tu-dresden.de/JOSM-Workshop-Graz/ Ich lass das dudle bis zum Do, 20.11. offen - wenn sich mindestens 3 Leute finden, verkünde ich den Termin nochmal hier, sonst gibt's den nächsten wahrscheinlich zu den Grazer Linuxtagen 2015. lg, Michael -- Michael Maier, Student of Telematics @ Graz University of Technology OpenStreetMap Graz http://osm.org/go/0Iz@paV http://wiki.osm.org/Graz http://wiki.osm.org/Graz/Stammtisch signature.asc Description: OpenPGP digital signature ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
[Talk-pt] Recalcular Rota - Aos programadores do OsmAnd +
Ao não virar à direita no local indicado pela aplicação OsmAnd+ verifiquei que me mandou virar depois à esquerda quando o caminho correcto mais curto seria ir em frente 100 metros em linha recta depois virar à direita em linha recta .. ao fim de 200 metros estou no destino. Conclusão ... em vez de andar 300 metros. ... teria andado cerca de 2 000 metros. Fiquei admirado porque tenho outras aplicações GPS. TomTom e Sygic que fazem o caminho correcto como aqui indiquei. Se for parecido indicarei o percurso que fiz. Espero que não dê muito trabalho fazer com que a aplicação OsmAnd+ faça o recalculo duma rota para o caminho mais curto. Cumprimentos. José Lázaro. ___ Talk-pt mailing list Talk-pt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-pt
[OSM-talk-fr] Proposition d'amélioration osmose - étiquette toujours au dessus de l'erreur
Bonjour J'ai une proposition d'amélioration d'osmose. Je crois que c'est pas le bon endroit, mais j'ai pas réussi à trouver le centre d'erreur d'osmose : L'étiquette qui développe l'erreur lorsque la souris passe au dessus d'un marqueur est toujours au dessus de ce dernier. Or, lorsque le marqueur est dans la partie haute de l'écran, l'étiquette sort du cadre. Je propose la solution suivante : Si le marqueur se trouve dans les 25 % haut de l'écran utilisateur, alors afficher l'étiquette en dessous du marqueur. Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Proposition d'amélioration osmose - étiquette toujours au dessus de l'erreur
Le 11 nov. 2014 à 10:44, David Crochet david.croc...@free.fr a écrit : Bonjour J'ai une proposition d'amélioration d'osmose. Je crois que c'est pas le bon endroit, mais j'ai pas réussi à trouver le centre d'erreur d'osmose » : C’est ici pour déposer un ticket : https://github.com/osm-fr/osmose-frontend/issues :-) — Yves ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Prochain SOTM France en 2015 à ....
Bonjour, Est-ce que les dates sont également fixées ? Ça peut paraitre lointain, mais certains agendas se remplissent plus vite que d'autres, y compris 6 mois à l'avance ! JB. Le 18/10/2014 13:23, Louis-Julien de la Bouëre a écrit : Bonjour à toutes et tous, Je suis heureux de vous annoncer que le CA d'OSM-fr a décider d'organiser le prochain SOTM France en Bretagne ! Il se déroulera en avril 2015 à Brest ! Je coordonnerai l'organisation de cet évènement. Pour l'instant tout est à construire... Voici quelques premiers éléments : - La thématique des rencontres serait autour d'OSM et Usages ! C'est une des spécialités brestoise autour du numérique et ça pourrait être la patte de cette édition. A discuter, valider. - En moins d'une journée, la nouvelle s'est propagée sur Brest : différents services de la ville m'ont contacté (internet, stratégie...) pour nous apporter leur soutien, puis l'université, certaines associations numériques et des discussions aussi autour d'une présence de membres du CNN. Bref ça bouge vite. Je vais travailler avec eux à la question des dates, lieux, détails techniques... Si vous avez des suggestions, je prends. je mettrais en place les outils pour que cette rencontre soit le plus partagée entre nous tous prochainement. J'aimerai que notre communauté bretonne-grand ouest en profite pour mieux se connaitre, travailler ensemble... en gros que nous puissions créer du lien sur notre territoire... En attendant les premiers avancements... Nous vous invitons toutes et tous sur Brest en avril 2015 ! Merci beaucoup pour vos retours et à très bientôt, Ken@vo ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Astellia aussi utilise OSM
Bonjour, Astellia, un des leader sur les solutions de monitoring de réseaux de téléphonie mobile et IP viens de tweeter quelque chose d'intéressant. https://twitter.com/Astellia_news/status/532150841000869888 Un de leur soft et pas des moindres, Nova, utiliserait OSM pour afficher la position des éléments d'un réseau mobile. Vu d'ici l'attribution y est, tout est parfait dans le meilleur des mondes ;) A+ *François Lacombe* fl dot infosreseaux At gmail dot com www.infos-reseaux.com @InfosReseaux http://www.twitter.com/InfosReseaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Prochain SOTM France en 2015 à ....
Louis-Julien de la Bouëre-2 wrote Je suis heureux de vous annoncer que le CA d'OSM-fr a décider d'organiser le prochain SOTM France en Bretagne ! Incidemment, pourquoi le site officiel est-il nativement en espagnol plutôt qu'en anglais? http://www.stateofthemap.org/ -- View this message in context: http://gis.19327.n5.nabble.com/Prochain-SOTM-France-en-2015-a-tp5820712p5823966.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Prochain SOTM France en 2015 à ....
Bonjour, Le 11/11/2014 14:22, Shohreh a écrit : Louis-Julien de la Bouëre-2 wrote Je suis heureux de vous annoncer que le CA d'OSM-fr a décider d'organiser le prochain SOTM France en Bretagne ! Incidemment, pourquoi le site officiel est-il nativement en espagnol plutôt qu'en anglais? http://www.stateofthemap.org/ Ce site est celui du SOTM mondial, qui vient de se terminer à Buenos Aires. Le prochain SOTM France aura lieu les 10-11-12 avril 2015 à Brest. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Prochain SOTM France en 2015 à ....
Le 11 nov. 2014 à 14:22, Shohreh codecompl...@free.fr a écrit : Louis-Julien de la Bouëre-2 wrote Je suis heureux de vous annoncer que le CA d'OSM-fr a décider d'organiser le prochain SOTM France en Bretagne ! Incidemment, pourquoi le site officiel est-il nativement en espagnol plutôt qu'en anglais? http://www.stateofthemap.org Respecter la langue des autres, -ici, les organisateurs argentins du SOTM 14-, est un des fondements de la paix civile. Ce n'est qu'après l'avoir fait, que l'on cherche les moyens de communication translangues. Christian R. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bano en panne ?
Bonjour, Est-ce qu'il y a eu un souci avec les scripts BANO cette nuit ? Le 44 vient de perdre environ 200 voies rapprochées, et à priori ce n'est pas le seul département dans cette situation, le rapprochement étant passé de 11.15 à 11.14 millions d'adresses. Si ce n'est pas un problème de script, est-ce qu'il y a un moyen simple de trouver dans quelles communes se situe le souci ? J'ai regardé layers.openstreetmap.fr au cas ou des frontières seraient cassées, mais ça ne semble pas être le cas. Stéphane Le vendredi 7 novembre 2014 10:04:11, Jérôme Seigneuret a écrit : En effet sur les Lieu-dit on en avait parlé avec Vincent et pour le moment c'est pas pris en compte. Vincent, les tickets que tu as mis sont-il le résultat de la discussion que l'on a pu avoir sur les erreurs à remonter pour Fantoir ou ça n'a pas de lien? En tous cas c'est cool déjà c'est de nouveau op. Le 7 novembre 2014 06:45, Vincent de Château-Thierry osm.v...@free.fr mailto:osm.v...@free.fr a écrit : Bonjour, Le 07/11/2014 00:34, Yves Pratter a écrit : Je constate que BANO / Fantoir ont repris du service : Merci :-) Oui ça repart, depuis 2j. J’ai encore trouvé une particularité ;-) Pour la commune de Myon 25416 http://cadastre.__openstreetmap.fr/fantoir/#__insee=25416 http://cadastre.openstreetmap.fr/fantoir/#insee=25416, il ne trouve pas « PL DE LA MAIRIE » alors qu’elle est bien créée : http://tile.openstreetmap.fr/~__cquest/leaflet/bano.html#20/__47.02559/5.94281 http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#20/47.02559/5.94281 BANO ne recherche que des polylignes, pas les surfaces ? J'ai créé le ticket https://github.com/osm-fr/osm-__vs-fantoir/issues/2 https://github.com/osm-fr/osm-vs-fantoir/issues/2 C'est un héritage direct du problème évoqué en commentaire ici : https://github.com/osm-fr/__bano/issues/62 https://github.com/osm-fr/bano/issues/62 Corriger le second devrait clore le premier. Question : L’adresse suivante correspond à un lieu-dit : « LE MARTINET » Je crée ce lieu-dit et BANO va le réutiliser tout seul ou est-ce que je dois créer le noeud adresse avec addr:place=Le Martinet ? Pour l'instant le schema addr:place, et les lieux-dits en général, ne sont pas considérés pour les rapprochements. Sur la tout (toux ?) doux. vincent _ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org https://lists.openstreetmap.__org/listinfo/talk-fr https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bano en panne ?
J'ai regardé layers.openstreetmap.fr au cas ou des frontières seraient cassées, mais ça ne semble pas être le cas. Je ne sais pas si c’est normal, mais au niveau : pays (admin2), il y a des « rectangles » bizarres en Pologne. admin3, beaucoup de pays ne sont pas coloriés Ensuite il y a des trous suivant les pays et les niveaux mais j’imagine que tous n’ont pas les mêmes subdivisions administratives. — Yves___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] BANO - Rapprochement avec et sans adresse
Coucou ! Je tombe sur un cas un peu bizarre : Ce n'est pas rare que la couche BANO affiche une rue non rapprochée, sans code Fantoir, mais qu'on le retrouve en passant par cadastre.openstreetmap.fr/fantoir. Sur Crossac (44), je vois une rue nommée Route de PontChâteauplanche mar http://layers.openstreetmap.fr/?zoom=18lat=47.42208lon=-2.14853layers=BFT. En réalité c'est la section de la Route de PontChâteau qui passe par le hameau La Planche Marion, avec 11 adresses. Sur la couche BANO, elle n'a pas de code fantoir. Ce qui est curieux, c'est que sur le site, je la trouve bien, avec le code fantoir 440500139R http://cadastre.openstreetmap.fr/fantoir/#insee=44050, mais dans la section Voies sans adresses. Stéphane ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-ja] 南会津 大内宿OSMマッピングパーティー開催！
南会津の大内宿でOSMマッピング＆散策会を11月8日（土）開催しました。参加された皆様お疲れ様でした。 ひんやりとした秋晴れのもと、午後１時集合マッピング＆散策1時間（そんなに広くないので）、お蕎麦屋さんで食事、コーヒーしながら、マッピング反省会、OSM雑談を1時間半して４時ごろ解散しました。 （日没までマッピングする居残り班もいましたが。。）やはり秋の紅葉シーズン、大内宿駐車場は混雑、入庫の列ができていました。 Wikiにまとめました。 https://wiki.openstreetmap.org/wiki/JA:Ouchi-juku_Mapping_Party_20141108 - Original Message - From: ikiya insidekiwi...@yahoo.co.jp To: 大和田健一 ml.ohw...@gmail.com; OpenStreetMap Japanese talk talk-ja@openstreetmap.org Date: 2014/11/6, Thu 00:35 Subject: Re: [OSM-ja] 南会津 大内宿OSMマッピングパーティー開催！ ikiyaです。 予定あわず、残念です。 参加したぞという気持ちだけ置いておきます。 ありがとうございます。 お時間ありましたら、新蕎麦、食べていってください。いっそう参加した気分になるかも。 - Original Message - From: 大和田健一 ml.ohw...@gmail.com To: ikiya insidekiwi...@yahoo.co.jp; OpenStreetMap Japanese talk talk-ja@openstreetmap.org Date: 2014/11/6, Thu 00:15 Subject: Re: [OSM-ja] 南会津 大内宿OSMマッピングパーティー開催！ あ〜、残念。 今日は、会津若松 に泊まっています。 明日は、帰りますが。 参加したぞという気持ちだけ置いておきます。 --- 大和田健一 ml.ohw...@gmail.com ikiyaです。 晩秋、美味しい新蕎麦の季節となりました。 ”お蕎麦を食べに行こう”からマッピングしようとなりました。 ショートノーティスですが、１１月８日（土） 重要伝統的建造物群保存地区となっている旧宿場大内宿を散策、マッピングします。 ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSRM-talk] OSRM backend v4.4.0 released
Hi Dennis, When do think you'll release distance matrix working with distance and time? Thanks. On Wed, Oct 22, 2014, 22:45 Helder Alves helderalve...@gmail.com wrote: Hi All, Where is that PR? I can't find it... Thanks. -- Helder Alves On Oct 22, 2014 2:33 PM, Dennis Luxen i...@project-osrm.org wrote: does this relese include the option to obtain both distance and time using the Distance matrix API? Unfortunately not. The contributor of the pull request in question decided not to work the patch into mergable form. So this has stalled in will arrive with a future release. --Dennis ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
Re: [Talk-us] User randomly adding speed limits across the US
On 2014-11-10 21:51, James Mast wrote: I'm just curious, but can anybody verify the speed limits that user msheerin17 [1] has been randomly adding across the US? He seems to fond of adding a lot of 'maxspeed=55 mph' tags to ways in completely different areas (he does add other speed limits, but well over 60% have been 55 mph). I have tried to contact this user about all the speed limits he's been adding and did get a response back from him only once (back on October 15th). In that response, he claimed he was getting the speed limits from our customers, but at no time did he mention what company he was working for or what app was generating the input from people of the 'correct speed limits'. He even told me to let him know if I had any more questions, but he's never responded to any other messages that I sent him after that asking about that info. I do know one changeset [2] was at least was partially correct (was for a small segment of PA-28 and I could verify that since I live near it), however, a small part he tagged @ 55 mph is still officially 45 mph (the NB bridge over PA-8 is posted @ 45 mph still, not 55 mph). However, there are other changesets out there that he did where there is no way possible the speed limit he added could be correct. [3] So, if anybody lives near any of his changesets were he's added the maxspeed tag and can verify if they are either correct or incorrect, I'd appreciate it. If he's been adding a lot of incorrect speed limits, we need to nip this in the behind fast before it gets too out of hand. If most of them are incorrect (being 15+ over the actual posted limit or more in some places), it could seriously cause problems with the routers that use OSM data, especially in areas where we don't have any active mappers to verify said speed limits. Heck, it could even lead to bad press if somebody gets a speeding ticket and they try to blame OSM for it because of the incorrect speed limit in the database. I spot-checked the 50 or so ways msheerin17 tagged in Ohio; the speed limits look plausible for the most part. Most are undivided rural roads, which are 55 or 60 mph by default. Suburban arterial roads with 45 or 50 mph limits aren't unheard of, either. My only beef with their changes is that they didn't split the ways up before tagging them. Roads leading into town, like [1] and [2], could well be 50 at one end but decrease in steps to only 25 at the other end. In fact, I know of several roads where the speed limit suddenly jumps from 25 to 55 at a village limit. Wikipedia has a table of statutory speed limits that may help assess their edits in other states. [3] [1] http://osm.org/way/302290438 [2] http://osm.org/way/19268121 [3] https://en.wikipedia.org/wiki/Speed_limits_in_the_United_States#Speed_limits -- m...@nguyen.cincinnati.oh.us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
