Re: [OSM-talk-be] Lanes turns from wich side you start to count?
Hi, It is simple: Look in the direction of the road= arrow (eg SN) Observe lane from left to right. In Belgium on a common street with 2 directions, the left side is in the reverse direction (eg 2 NS) and the right side lanes goes in the direction of the arrow (eg 3 SN). So you have in the strait piece of the road: turn:lanes:backward=none|none turn:lanes:forward=none|none|none For the turning itself before a crossing you consider the direction of the lane: eg NS outside lane (1) is for turning right and going through, inside lane is for turning left (by crossing other 3 lanes) turn:lanes:backward=right|through;left In the forward direction (SN) is eg a lane for every direction turn:lanes:forward=left|through|right The last and outside lane (5) is of course for turning right. Regards, Gerard Jakka wrote: Hi, Reading en try to understand lanes and turns wiki's https://wiki.openstreetmap.org/wiki/Key:turn In Belgium right side driving how do I compose my value key of de lanes? I get confuse with the wiki images and explanations in it. Not going in detail yet only the positions of lanes. For i go futher to understand the next wiki. OSM direction (arrows) south to north lanes=5 2 north to south and 3 south to north nummerique counting from left to right 1,2,3,4,5 so I split north to south thats something with backward turn:lanes:backward 1|2 so I split south to north thats something with forward turn:lanes:forward 3|4|5 or is it from right to left? 5|4|3|2|1?? Or the lanes them self left to right or right to left. Sorry I am lost here ___ 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] Lanes turns from wich side you start to count?
Oops! turn:lanes:backward=right|through;left should be turn:lanes:backward=right;through|left Gerard Vanderveken wrote: Hi, It is simple: Look in the direction of the road= arrow (eg SN) Observe lane from left to right. In Belgium on a common street with 2 directions, the left side is in the reverse direction (eg 2 NS) and the right side lanes goes in the direction of the arrow (eg 3 SN). So you have in the strait piece of the road: turn:lanes:backward=none|none turn:lanes:forward=none|none|none For the turning itself before a crossing you consider the direction of the lane: eg NS outside lane (1) is for turning right and going through, inside lane is for turning left (by crossing other 3 lanes) turn:lanes:backward=right|through;left In the forward direction (SN) is eg a lane for every direction turn:lanes:forward=left|through|right The last and outside lane (5) is of course for turning right. Regards, Gerard Jakka wrote: Hi, Reading en try to understand lanes and turns wiki's https://wiki.openstreetmap.org/wiki/Key:turn In Belgium right side driving how do I compose my value key of de lanes? I get confuse with the wiki images and explanations in it. Not going in detail yet only the positions of lanes. For i go futher to understand the next wiki. OSM direction (arrows) south to north lanes=5 2 north to south and 3 south to north nummerique counting from left to right 1,2,3,4,5 so I split north to south thats something with backward turn:lanes:backward 1|2 so I split south to north thats something with forward turn:lanes:forward 3|4|5 or is it from right to left? 5|4|3|2|1?? Or the lanes them self left to right or right to left. Sorry I am lost here ___ 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 ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
[OSM-talk-be] Verplicht rechts afslaan
Op punt: 50.9801192 / 4.4599431 in Zemst komt de Edgar Tinelstraat uit op de Brusselsesteenweg. Het autoverkeer dat uit de Edgar Tinelstraat komt moet verplicht rechts afslaan. Hoe kan ik zo iets mappen zonder het mooie werk dat Glenn daar geleverd heeft te beschadigen? Guy Vanvuchelen ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Lanes turns from wich side you start to count?
Thanks, One step further: turn:lanes:backward=right;through|left Which must you put first is this strictly? turn:lanes:backward=the direction change;continue|left or turn:lanes:backward=continue;the direction change|left Gerard Vanderveken schreef op 30/11/2014 om 13:24: Oops! turn:lanes:backward=right|through;left should be turn:lanes:backward=right;through|left Gerard Vanderveken wrote: Hi, It is simple: Look in the direction of the road= arrow (eg SN) Observe lane from left to right. In Belgium on a common street with 2 directions, the left side is in the reverse direction (eg 2 NS) and the right side lanes goes in the direction of the arrow (eg 3 SN). So you have in the strait piece of the road: turn:lanes:backward=none|none turn:lanes:forward=none|none|none For the turning itself before a crossing you consider the direction of the lane: eg NS outside lane (1) is for turning right and going through, inside lane is for turning left (by crossing other 3 lanes) turn:lanes:backward=right|through;left In the forward direction (SN) is eg a lane for every direction turn:lanes:forward=left|through|right The last and outside lane (5) is of course for turning right. Regards, Gerard Jakka wrote: Hi, Reading en try to understand lanes and turns wiki's https://wiki.openstreetmap.org/wiki/Key:turn In Belgium right side driving how do I compose my value key of de lanes? I get confuse with the wiki images and explanations in it. Not going in detail yet only the positions of lanes. For i go futher to understand the next wiki. OSM direction (arrows) south to north lanes=5 2 north to south and 3 south to north nummerique counting from left to right 1,2,3,4,5 so I split north to south thats something with backward turn:lanes:backward 1|2 so I split south to north thats something with forward turn:lanes:forward 3|4|5 or is it from right to left? 5|4|3|2|1?? Or the lanes them self left to right or right to left. Sorry I am lost here ___ 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 ___ 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] Verplicht rechts afslaan
Dat hoef je niet te doen, want dat heeft Glenn al gemapt. Kijk naar http://www.openstreetmap.org/relation/2709163/ voor de manier waarop het gebeurd is. André Engels 2014-11-30 14:31 GMT+01:00 Guy Vanvuchelen guy.vanvuche...@gmail.com: Op punt: 50.9801192 / 4.4599431 in Zemst komt de Edgar Tinelstraat uit op de Brusselsesteenweg. Het autoverkeer dat uit de Edgar Tinelstraat komt moet verplicht rechts afslaan. Hoe kan ik zo iets mappen zonder het mooie werk dat Glenn daar geleverd heeft te beschadigen? Guy Vanvuchelen ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be -- André Engels, andreeng...@gmail.com ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Lanes turns from wich side you start to count?
Sorry, maar turn:lanes:xxx=right;through|left kan nooit bij rechtsrijdend verkeer. (hoop ik :-) ) De lanes worden altijd bekeken in de richting dat je rijdt. Het linker rijvak (in de richting dat je rijdt) komt altijd eerst: het is altijd left|through;right: linker rijvak om links af te slaan, rechter rijvak om rechtdoor te rijden en rechts af te slaan. Dit is onafhankelijk van de richting van de way pijl in OSM. De xxx wordt forward als het in de richting van de OSM-weg is, backward in de tegengestelde richting. Installeer de kaarttekenstyle lane road attributes in JOSM, onmisbaar voor dit soort werk. Dan zie je de pijlen. Weet je onmiddellijk of je goed bezig bent. Verder kan http://wiki.openstreetmap.org/wiki/Lanes je misschien ook helpen Ik heb onlangs al wat wegen in Kortrijk en Harelbeke van de nodige lanes/turn:lanes voorzien. 'k ben nu bezig rond Aalst. In de Prov Antwerpen Limburg en rond Gent zijn alle vele motorways/trunks/primary roads al gedaan. Voorbeelden genoeg hoop ik. Kijk maar naar een van de changesets van Escada [1] met de commentaar lanes; turn:lanes veel succes m [1] http://www.openstreetmap.org/user/escada/history On Sun, Nov 30, 2014 at 2:32 PM, Jakka vdmfrank...@gmail.com wrote: Thanks, One step further: turn:lanes:backward=right;through|left Which must you put first is this strictly? turn:lanes:backward=the direction change;continue|left or turn:lanes:backward=continue;the direction change|left Gerard Vanderveken schreef op 30/11/2014 om 13:24: Oops! turn:lanes:backward=right|through;left should be turn:lanes:backward=right;through|left Gerard Vanderveken wrote: Hi, It is simple: Look in the direction of the road= arrow (eg SN) Observe lane from left to right. In Belgium on a common street with 2 directions, the left side is in the reverse direction (eg 2 NS) and the right side lanes goes in the direction of the arrow (eg 3 SN). So you have in the strait piece of the road: turn:lanes:backward=none|none turn:lanes:forward=none|none|none For the turning itself before a crossing you consider the direction of the lane: eg NS outside lane (1) is for turning right and going through, inside lane is for turning left (by crossing other 3 lanes) turn:lanes:backward=right|through;left In the forward direction (SN) is eg a lane for every direction turn:lanes:forward=left|through|right The last and outside lane (5) is of course for turning right. Regards, Gerard Jakka wrote: Hi, Reading en try to understand lanes and turns wiki's https://wiki.openstreetmap.org/wiki/Key:turn In Belgium right side driving how do I compose my value key of de lanes? I get confuse with the wiki images and explanations in it. Not going in detail yet only the positions of lanes. For i go futher to understand the next wiki. OSM direction (arrows) south to north lanes=5 2 north to south and 3 south to north nummerique counting from left to right 1,2,3,4,5 so I split north to south thats something with backward turn:lanes:backward 1|2 so I split south to north thats something with forward turn:lanes:forward 3|4|5 or is it from right to left? 5|4|3|2|1?? Or the lanes them self left to right or right to left. Sorry I am lost here ___ 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 ___ 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 ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Lanes turns from wich side you start to count?
The order is from left to right as seen in the direction of the traffic https://wiki.openstreetmap.org/wiki/Lanes#Two_driving_directions, not the road (arrow). There is a style for Josm https://wiki.openstreetmap.org/wiki/Lanes#JOSM, that visualises the road. Jakka wrote: Thanks, One step further: turn:lanes:backward=right;through|left Which must you put first is this strictly? turn:lanes:backward=the direction change;continue|left or turn:lanes:backward=continue;the direction change|left Gerard Vanderveken schreef op 30/11/2014 om 13:24: Oops! turn:lanes:backward=right|through;left should be turn:lanes:backward=right;through|left Gerard Vanderveken wrote: Hi, It is simple: Look in the direction of the road= arrow (eg SN) Observe lane from left to right. In Belgium on a common street with 2 directions, the left side is in the reverse direction (eg 2 NS) and the right side lanes goes in the direction of the arrow (eg 3 SN). So you have in the strait piece of the road: turn:lanes:backward=none|none turn:lanes:forward=none|none|none For the turning itself before a crossing you consider the direction of the lane: eg NS outside lane (1) is for turning right and going through, inside lane is for turning left (by crossing other 3 lanes) turn:lanes:backward=right|through;left In the forward direction (SN) is eg a lane for every direction turn:lanes:forward=left|through|right The last and outside lane (5) is of course for turning right. Regards, Gerard Jakka wrote: Hi, Reading en try to understand lanes and turns wiki's https://wiki.openstreetmap.org/wiki/Key:turn In Belgium right side driving how do I compose my value key of de lanes? I get confuse with the wiki images and explanations in it. Not going in detail yet only the positions of lanes. For i go futher to understand the next wiki. OSM direction (arrows) south to north lanes=5 2 north to south and 3 south to north nummerique counting from left to right 1,2,3,4,5 so I split north to south thats something with backward turn:lanes:backward 1|2 so I split south to north thats something with forward turn:lanes:forward 3|4|5 or is it from right to left? 5|4|3|2|1?? Or the lanes them self left to right or right to left. Sorry I am lost here ___ 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 ___ 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 ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Lanes turns from wich side you start to count?
Hi, Iemand eens tijd om te verifiëren. https://www.openstreetmap.org/#map=17/50.77395/3.18651 Heb hier een ontbrekende afslag moeten bijtekenen naar LAR geen verkeerslichten. Twee relaties aangemaakt (was zwoegen). Een beperking motorvoertuigen behalve landbouwvoertuigen beide richtingen N58 naar Brun Cornet ingevoerd. Komende van zuid of onder. Zit met twijfel met de voor sorteringspijlen om naar Brun Cornet in te slaan. Voor de afslag naar LAR zijn er 3 lanes left|trough|right gaat dan over naar 2 lanes dit uitgewerkt via relatie of moet daar ook turn:lanes=left|none bijkomen ? Is maar voor tractoren? sorry no english difficult to explain. Jakka Marc Gemis schreef op 30/11/2014 om 17:32: Sorry, maar turn:lanes:xxx=right;through|left kan nooit bij rechtsrijdend verkeer. (hoop ik :-) ) De lanes worden altijd bekeken in de richting dat je rijdt. Het linker rijvak (in de richting dat je rijdt) komt altijd eerst: het is altijd left|through;right: linker rijvak om links af te slaan, rechter rijvak om rechtdoor te rijden en rechts af te slaan. Dit is onafhankelijk van de richting van de way pijl in OSM. De xxx wordt forward als het in de richting van de OSM-weg is, backward in de tegengestelde richting. Installeer de kaarttekenstyle lane road attributes in JOSM, onmisbaar voor dit soort werk. Dan zie je de pijlen. Weet je onmiddellijk of je goed bezig bent. Verder kan http://wiki.openstreetmap.org/wiki/Lanes je misschien ook helpen Ik heb onlangs al wat wegen in Kortrijk en Harelbeke van de nodige lanes/turn:lanes voorzien. 'k ben nu bezig rond Aalst. In de Prov Antwerpen Limburg en rond Gent zijn alle vele motorways/trunks/primary roads al gedaan. Voorbeelden genoeg hoop ik. Kijk maar naar een van de changesets van Escada [1] met de commentaar lanes; turn:lanes veel succes m [1] http://www.openstreetmap.org/user/escada/history On Sun, Nov 30, 2014 at 2:32 PM, Jakka vdmfrank...@gmail.com mailto:vdmfrank...@gmail.com wrote: Thanks, One step further: turn:lanes:backward=right;__through|left Which must you put first is this strictly? turn:lanes:backward=the direction change;continue|left or turn:lanes:backward=continue;__the direction change|left Gerard Vanderveken schreef op 30/11/2014 om 13:24: Oops! turn:lanes:backward=right|__through;left should be turn:lanes:backward=right;__through|left Gerard Vanderveken wrote: Hi, It is simple: Look in the direction of the road= arrow (eg SN) Observe lane from left to right. In Belgium on a common street with 2 directions, the left side is in the reverse direction (eg 2 NS) and the right side lanes goes in the direction of the arrow (eg 3 SN). So you have in the strait piece of the road: turn:lanes:backward=none|none turn:lanes:forward=none|none|__none For the turning itself before a crossing you consider the direction of the lane: eg NS outside lane (1) is for turning right and going through, inside lane is for turning left (by crossing other 3 lanes) turn:lanes:backward=right|__through;left In the forward direction (SN) is eg a lane for every direction turn:lanes:forward=left|__through|right The last and outside lane (5) is of course for turning right. Regards, Gerard Jakka wrote: Hi, Reading en try to understand lanes and turns wiki's https://wiki.openstreetmap.__org/wiki/Key:turn https://wiki.openstreetmap.org/wiki/Key:turn In Belgium right side driving how do I compose my value key of de lanes? I get confuse with the wiki images and explanations in it. Not going in detail yet only the positions of lanes. For i go futher to understand the next wiki. OSM direction (arrows) south to north lanes=5 2 north to south and 3 south to north nummerique counting from left to right 1,2,3,4,5 so I split north to south thats something with backward turn:lanes:backward 1|2 so I split south to north thats something with forward turn:lanes:forward 3|4|5 or is it from right to left? 5|4|3|2|1?? Or the lanes them self left to right or right to left. Sorry I am lost here _ Talk-be mailing list Talk-be@openstreetmap.org mailto:Talk-be@openstreetmap.org
Re: [OSM-talk-be] Lanes turns from wich side you start to count?
Ik vind die access=no op de N58 vreemd. Het is through (en niet though). Heb ik net gecorrigeerd. Als je die tekenstijl installeert, dan komt er een foutmelding op de weg. Ik zou de afslag beperking N58 (vanuit Zuiden) naar Lar alleen rechtdoor maken. Om rechts af te slaan moet je dit nieuw stukje dat jij hebt getekend gebruiken. Het stukje N58 na die afslag naar rechts, 2 lanes, turn:lanes=left|through Ik gebruik zelf dikwijls none als ik geen pijl zie. Zelf gebruik ik ook placement heel veel. http://wiki.openstreetmap.org/wiki/Proposed_features/placement Ik weet het, het is een proposal, maar daar lig ik niet van wakker. :-) 2014-11-30 18:09 GMT+01:00 Jakka vdmfrank...@gmail.com: Hi, Iemand eens tijd om te verifiëren. https://www.openstreetmap.org/#map=17/50.77395/3.18651 Heb hier een ontbrekende afslag moeten bijtekenen naar LAR geen verkeerslichten. Twee relaties aangemaakt (was zwoegen). Een beperking motorvoertuigen behalve landbouwvoertuigen beide richtingen N58 naar Brun Cornet ingevoerd. Komende van zuid of onder. Zit met twijfel met de voor sorteringspijlen om naar Brun Cornet in te slaan. Voor de afslag naar LAR zijn er 3 lanes left|trough|right gaat dan over naar 2 lanes dit uitgewerkt via relatie of moet daar ook turn:lanes=left|none bijkomen ? Is maar voor tractoren? sorry no english difficult to explain. Jakka Marc Gemis schreef op 30/11/2014 om 17:32: Sorry, maar turn:lanes:xxx=right;through|left kan nooit bij rechtsrijdend verkeer. (hoop ik :-) ) De lanes worden altijd bekeken in de richting dat je rijdt. Het linker rijvak (in de richting dat je rijdt) komt altijd eerst: het is altijd left|through;right: linker rijvak om links af te slaan, rechter rijvak om rechtdoor te rijden en rechts af te slaan. Dit is onafhankelijk van de richting van de way pijl in OSM. De xxx wordt forward als het in de richting van de OSM-weg is, backward in de tegengestelde richting. Installeer de kaarttekenstyle lane road attributes in JOSM, onmisbaar voor dit soort werk. Dan zie je de pijlen. Weet je onmiddellijk of je goed bezig bent. Verder kan http://wiki.openstreetmap.org/wiki/Lanes je misschien ook helpen Ik heb onlangs al wat wegen in Kortrijk en Harelbeke van de nodige lanes/turn:lanes voorzien. 'k ben nu bezig rond Aalst. In de Prov Antwerpen Limburg en rond Gent zijn alle vele motorways/trunks/primary roads al gedaan. Voorbeelden genoeg hoop ik. Kijk maar naar een van de changesets van Escada [1] met de commentaar lanes; turn:lanes veel succes m [1] http://www.openstreetmap.org/user/escada/history On Sun, Nov 30, 2014 at 2:32 PM, Jakka vdmfrank...@gmail.com mailto:vdmfrank...@gmail.com wrote: Thanks, One step further: turn:lanes:backward=right;__through|left Which must you put first is this strictly? turn:lanes:backward=the direction change;continue|left or turn:lanes:backward=continue;__the direction change|left Gerard Vanderveken schreef op 30/11/2014 om 13:24: Oops! turn:lanes:backward=right|__through;left should be turn:lanes:backward=right;__through|left Gerard Vanderveken wrote: Hi, It is simple: Look in the direction of the road= arrow (eg SN) Observe lane from left to right. In Belgium on a common street with 2 directions, the left side is in the reverse direction (eg 2 NS) and the right side lanes goes in the direction of the arrow (eg 3 SN). So you have in the strait piece of the road: turn:lanes:backward=none|none turn:lanes:forward=none|none|__none For the turning itself before a crossing you consider the direction of the lane: eg NS outside lane (1) is for turning right and going through, inside lane is for turning left (by crossing other 3 lanes) turn:lanes:backward=right|__through;left In the forward direction (SN) is eg a lane for every direction turn:lanes:forward=left|__through|right The last and outside lane (5) is of course for turning right. Regards, Gerard Jakka wrote: Hi, Reading en try to understand lanes and turns wiki's https://wiki.openstreetmap.__org/wiki/Key:turn https://wiki.openstreetmap.org/wiki/Key:turn In Belgium right side driving how do I compose my value key of de lanes? I get confuse with the wiki images and explanations in it. Not going in detail yet only the positions of lanes. For i go futher to understand the next wiki. OSM direction (arrows) south to north lanes=5
Re: [OSM-talk] Landuse vs Vegetation vs Landcover proposed cleanup at wiki
On Sun, Nov 30, 2014 at 11:04:28AM +0400, Никита wrote: We have highly inconsistent content at wiki (feature pages http://wiki.openstreetmap.org/wiki/Category:Features). Inconsistency is not limited to landuse=wood/natural=forest. Another example is landuse=meadow (Landuse http://wiki.openstreetmap.org/wiki/Landuse, Vegetation http://wiki.openstreetmap.org/wiki/Vegetation, Landcover http://wiki.openstreetmap.org/wiki/Landcover). We should think about how to organize content without collisions or at very least place all problematic categories under same Feature (semi-temporary, until we have better idea). definitely a good idea. However - *do not overhasten this* The last thing we can need is another halfbaken temporary compromise. Personally I suggest to use name environment - yes, it broader than anything (Landuse http://wiki.openstreetmap.org/wiki/Landuse, Vegetation http://wiki.openstreetmap.org/wiki/Vegetation, Landcover http://wiki.openstreetmap.org/wiki/Landcover). It is also not limited to Natural environment http://en.wikipedia.org/wiki/Natural_environment (then we cannot use Landuse/amenity) It is not limited to Physical environment http://en.wikipedia.org/wiki/Ecology#Physical_environments (we have semi/virual features like landuse/amenity because The problem is not only that forest can be mapped as either landuse,landcover or natural. We must also go away from the - there is either rock, vegetation or residential area model. Furthermore our vegetation model - there be either forest or gras is woefully inadequate. We need vegetation layers (ground, shrub level, under canopy, canopy, emergents). We need lots of fine tuning in geology as well. Instead we need the possibility to say * 70% landcover is sand (+ material where known) * 10% larger rocks (+ main rock type) - spatial extension of those areas may not be identical * ground level vegetation is gras, covering XX% area * shrub level is Ocotillo, with 100 plants per 100 sqm - again spatial extension of those areas may not be identical Combine that with residential and other areas.. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Skybox for good imagery test
This is not what Skybox has stated publicly (later), seehttps://lists.openstreetmap.org/pipermail/legal-talk/2014-November/008053.html https://lists.openstreetmap.org/pipermail/legal-talk/2014-November/008053.html This may or may not be in conflict with what Mikel wrote, but in any case there is more than enough fuzziness to sit quiet at this point in time. Simon Thanks Simon, I hadn't seen that. Will speak with Mikel. Rob ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Landuse vs Vegetation vs Landcover proposed cleanup at wiki
If I understand correctly we are talking about combining 3 similar wiki pages into 1, not changing any tagging, in which case it makes sense. In my opinion the wiki needs more how to tag instructions (e.g. links to videos showing how in basic mode in most popular editors) as well as the existing tag documentation. Having one place to look for the different ground use tags, even if 3 sections on 1 page, is a good step towards making things easier for new mappers. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] some secondary services reduced this weekend
I missed this announcement on Friday. https://twitter.com/OSM_Tech/status/538394075448479744 Short notice: Few secondary OSM services offline this weekend due to power upgrades. Dev, OSMF blog, gpx tiles. Nominatim may be disrupted. Followup indicates that nominatim is fine. Big thank you @lontanviadi @sp8962 Despite main server outage over this weekend the #openstreetmap #nominatim is online available. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Issues with Mapbox paid mappers
Am 28.11.2014 um 21:31 schrieb Paul Johnson: Curious how I get on as a Mapbox paid mapper. +1 Might have some time for mapping and do not mind if it gets paid. colliar 0xE8F56581.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] Forum en mailinglijst: 2 kapiteins op hetzelfde schip?
hallo lijsters, Op het andere net (http://forum.openstreetmap.org/viewforum.php?id=12) is deze thread inmiddels overgegaan in een vrolijke beschouwing over de geschiedenis van het OSM-(NL)-forum. Een aanrader! Voordat je nu direct gaat zappen nog even oogsten: a) er is op het forum allerlei info de revue is gepasseerd over het op maat maken van gebruikersinstellingen van het forum (verwittigingen bij nieuwe onderwerpen en/of nieuwe berichten) b) er is sticky note (plaknotitie?) op het NL-forum is opgenomen met uitleg over bestaan en werking van deze mailinglijst. c) de veel geuite wens voor een technische koppeling tussen forum en lijst blijft er vooralsnog een voor de verlanglijst. Nog 2 suggesties/vragen 1) Kan de mailinglijst zich als lid kan aanmelden op het NL-forum? Of gaat dat technisch (of sociaal-cultureel ;-) ) te ver qua integratie? 2) Een verwijzing (in de ondertekening?) van deze mailinglijst naar het bestaan van het NL-forum kan ook bij dragen aan de vindbaarheid. Kan iemand dat arrangeren? groet, Gert-Jan ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Forum en mailinglijst: 2 kapiteins op hetzelfde schip?
Bedankt Stefan voor deze opheldering! On 2014-11-30 00:24, Stefan de Bonink wrote: On Saturday, November 29, 2014 2:32:32 PM CEST, Lambertus wrote: Eventuele insinuaties van machtsmisbruik op het forum zonder bewijs neem ik zeer serieus en kwalijk. Ik heb meer ervaring met /andere/ Nederlandse fora, waar ik een aantal jaren geleden al afgescheid van heb genomen door bovengenoemde ongelijkheid. Het ging mij om het online medium in het algemeen. Dus het had een moeten worden, mijn fout, excuses daarvoor. Uiteraard ben ik, en vele anderen, blij dat jullie het forum rechtvaardig modereren en technisch beschikbaar houden. Juist die houding voorkomt het beschreven dystopische forum. ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Welke tags voor straten in de bebouwde kom?
On 2014-11-28 17:02, Marc Zoutendijk wrote: Ik plaatste dit bericht [1] ook al eerder in het forum, maar wil graag horen hoe op de mailinglist over dit onderwerp wordt gedacht. Het gaat over welke tags gebruikt zouden moeten worden om (woon) straten in de bebouwde kom te taggen. Zelf gebruik ik de werkwijze dat alle bewoonde straten binnen landuse=residential: 1 residential 2 of living_street zijn Voor de grotere verbindingswegen tussen wijken is de wiki ook duidelijk (secondary of tertiary). highway=unclassified gebruik je dan voor die wegen buiten de bebouwde kom die niet tot de genummerde wegen behoren of voor wegen op bv. industrieterreinen. Maar highway=unclassified zou feitelijk in de bebouwde kom niet echt veel voor mogen komen. Toen ik dat eens ging onderzoeken bleek dat in Nederland complete steden getagd zijn met die unclassified tag. Dat komt omdat de AND import geen wegen als residential zijn geimporteerd. Maar moeten we dat niet gaan veranderen? Want nu staat er echt heel veel verkeerd. Ik zie niet wat er verkeerd gaat. Wat is er mis met een weg binnen de bebouwde kom die als unclassified is getagd? Als ik ze zelf tegenkom en ik wijzig iets aan de weg (meestal maxspeed) dan verander ik de highway tag ook. Eigenlijk makkelijk: 30 km/h is altijd residential, 50 km/h is vrijwel altijd residential (het kan natuurlijk buiten de bebouwde kom liggen. En wie gaat dat veranderen? Kan dat niet geautomatiseerd worden? Zijn er bezwaren? Bezwaren: wat is er mis en waarom zou je het geautomatiseerd willen veranderen. Maarten ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Forum en mailinglijst: 2 kapiteins op hetzelfde schip?
Daarvoor moet je Henk Hoff of Martijn van Exel benaderen. On Nov 30, 2014 11:31 AM, Gert-Jan van der Weijden gee...@dds.nl wrote: hallo lijsters, 2) Een verwijzing (in de ondertekening?) van deze mailinglijst naar het bestaan van het NL-forum kan ook bij dragen aan de vindbaarheid. Kan iemand dat arrangeren? groet, Gert-Jan ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Welke tags voor straten in de bebouwde kom?
2014-11-28 17:02 GMT+01:00 Marc Zoutendijk marczoutend...@mac.com: Ik plaatste dit bericht [1] ook al eerder in het forum, maar wil graag horen hoe op de mailinglist over dit onderwerp wordt gedacht. Het gaat over welke tags gebruikt zouden moeten worden om (woon) straten in de bebouwde kom te taggen. Zelf gebruik ik de werkwijze dat alle bewoonde straten binnen landuse=residential: 1 residential 2 of living_street zijn Voor de grotere verbindingswegen tussen wijken is de wiki ook duidelijk (secondary of tertiary). highway=unclassified gebruik je dan voor die wegen buiten de bebouwde kom die niet tot de genummerde wegen behoren of voor wegen op bv. industrieterreinen. Maar highway=unclassified zou feitelijk in de bebouwde kom niet echt veel voor mogen komen. Daar ben ik het niet mee eens. Ik gebruik zelf highway=unclassified voor wegen die meer dan alleen woonstraten zijn, maar niet groot genoeg voor tertiary, bijvoorbeeld een hoofdstraat door een wijk. En ook voor wegen die binnen de bebouwde kom meer een woonstraat zijn, maar ook buiten de bebouwde kom doorgaan als unclassified. De oorzaak (in Nederland) is dat bijna al die wegen destijds binnengehaald zijn met een grote AND import en daar stond die tag erbij. Maar moeten we dat niet gaan veranderen? Want nu staat er echt heel veel verkeerd. En wie gaat dat veranderen? Kan dat niet geautomatiseerd worden? Zijn er bezwaren? Ikzelf probeer het meestal te veranderen als ik een gebied aan het bewerken ben; probleem hiermee is dat het zo nog wel 10 jaar duurt voor dit weer echt fatsoenlijk is. Automatisering is problematisch omdat we dan gemakkelijk naar het omgekeerde probleem overgaan - wegen die wel unclassified moeten blijven, maar naar residential worden gezet. Wellicht zouden we iets halfautomatisch kunnen bedenken (waarbij iemand een stukje kaart te zien krijgt, en dan aangeeft welke unclassified en welke residential moeten zijn (bij voorkeur als 'deze unclassified/residential en de rest het andere), maar ik weet niet hoeveel sneller dat zou gaan dan mensen in hun eigen favoriete editor late werken. -- André Engels, andreeng...@gmail.com ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Maximum snelheid N270
On 11/13/2014 06:29 PM, Maarten Deen wrote: On 2014-11-13 17:11, Pander OpenTaal wrote: Over Nuenen gesproken, de weg van Venray naar Nuenen heeft afwijkende maximale snelheid in werkelijkheid t.o.v. wat OsmAnd meldt. Mocht iemand dat willen aanpassen is dat welkom. Welk gedeelte. Van Venray naar Helmond staat het op 80, dat zal wel kloppen. Door Helmond is het 50, ik denk dat het alleen het stuk tussen Helmond en Eindhoven is wat op plaatsen niet klopt. Daar is de laatste tijd wel wat gewijzigd met de Brandevoort dreef en ik kom er ook niet elke dag. Als je er was, kun je aangeven wat precies niet klopt? Er waren meer verschillende snelheden. Weet het helaas niet meer uit mijn hoofd. Aangezien ik daar verder nooit kom en ik aandacht bij de weg moest houden leek het me onverstandig om aantekeningen te maken tijdens het rijden. Misschien kan iemand die daar regelmatig rijdt het herzien of meer informatie verstrekken. Maarten ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl -- Stichting OpenTaal http://opentaal.org http://twitter.com/opentaal ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Welke tags voor straten in de bebouwde kom?
Op 30 nov. 2014, om 14:14 heeft Maarten Deen md...@xs4all.nl het volgende geschreven: Dat komt omdat de AND import geen wegen als residential zijn geimporteerd. Dat was me inmiddels duidelijk geworden. Maar moeten we dat niet gaan veranderen? Want nu staat er echt heel veel verkeerd. Ik zie niet wat er verkeerd gaat. Wat is er mis met een weg binnen de bebouwde kom die als unclassified is getagd? Wat er in mijn ogen nu niet klopt is dat op OpenStreetMap soortgelijke straten op verschillende manieren worden getagd. Als heel Brussel vol ligt met residentials en heel Amsterdam met unclassifieds - terwijl het om dezelfde soort straten gaat - dan is dat toch niet helder voor de gebruiker? En als je zelf (zoals je hieronder schrijft) dat dus wijzigt, dan is er dus klaarbkijkelijk ook in jouw ogen iets niet in orde met die tagging. Als ik ze zelf tegenkom en ik wijzig iets aan de weg (meestal maxspeed) dan verander ik de highway tag ook. Eigenlijk makkelijk: 30 km/h is altijd residential, 50 km/h is vrijwel altijd residential (het kan natuurlijk buiten de bebouwde kom liggen. En wie gaat dat veranderen? Kan dat niet geautomatiseerd worden? Zijn er bezwaren? Bezwaren: wat is er mis en waarom zou je het geautomatiseerd willen veranderen. Ik zou het geautomariseerd willen doen vanwege het grote aantal straten, maar dat stuit op veel te veel bezwaren omdat er dan ten onrechte straten worden gewijzigd die niet gewijzigd mogen worden. Want er zijn wel degelijk straten die met recht UCL hebben binnen de bebouwde kom. Als alle andere tags op de straten correct zouden zijn (zoals bv. de snelheidslimiet) dan zou je nog een filter kunnen maken: If (speedlimit = 30) AND (highway=unclassified) then highway = residential Maar in de meeste gevallen zijn die andere tags er niet. Mijn conclusie is dan ook: het wordt handwerk. Marc. ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Welke tags voor straten in de bebouwde kom?
Je kan altijd een MapRoulette project opzetten. dan kan het heel vlug gaan. 2014-11-30 16:48 GMT+01:00 Marc Zoutendijk marczoutend...@mac.com: Op 30 nov. 2014, om 14:14 heeft Maarten Deen md...@xs4all.nl het volgende geschreven: Dat komt omdat de AND import geen wegen als residential zijn geimporteerd. Dat was me inmiddels duidelijk geworden. Maar moeten we dat niet gaan veranderen? Want nu staat er echt heel veel verkeerd. Ik zie niet wat er verkeerd gaat. Wat is er mis met een weg binnen de bebouwde kom die als unclassified is getagd? Wat er in mijn ogen nu niet klopt is dat op OpenStreetMap soortgelijke straten op verschillende manieren worden getagd. Als heel Brussel vol ligt met residentials en heel Amsterdam met unclassifieds - terwijl het om dezelfde soort straten gaat - dan is dat toch niet helder voor de gebruiker? En als je zelf (zoals je hieronder schrijft) dat dus wijzigt, dan is er dus klaarbkijkelijk ook in jouw ogen iets niet in orde met die tagging. Als ik ze zelf tegenkom en ik wijzig iets aan de weg (meestal maxspeed) dan verander ik de highway tag ook. Eigenlijk makkelijk: 30 km/h is altijd residential, 50 km/h is vrijwel altijd residential (het kan natuurlijk buiten de bebouwde kom liggen. En wie gaat dat veranderen? Kan dat niet geautomatiseerd worden? Zijn er bezwaren? Bezwaren: wat is er mis en waarom zou je het geautomatiseerd willen veranderen. Ik zou het geautomariseerd willen doen vanwege het grote aantal straten, maar dat stuit op veel te veel bezwaren omdat er dan ten onrechte straten worden gewijzigd die niet gewijzigd mogen worden. Want er zijn wel degelijk straten die met recht UCL hebben binnen de bebouwde kom. Als alle andere tags op de straten correct zouden zijn (zoals bv. de snelheidslimiet) dan zou je nog een filter kunnen maken: If (speedlimit = 30) AND (highway=unclassified) then highway = residential Maar in de meeste gevallen zijn die andere tags er niet. Mijn conclusie is dan ook: het wordt handwerk. Marc. ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Welke tags voor straten in de bebouwde kom?
On 2014-11-30 16:48, Marc Zoutendijk wrote: Op 30 nov. 2014, om 14:14 heeft Maarten Deen md...@xs4all.nl het volgende geschreven: Maar moeten we dat niet gaan veranderen? Want nu staat er echt heel veel verkeerd. Ik zie niet wat er verkeerd gaat. Wat is er mis met een weg binnen de bebouwde kom die als unclassified is getagd? Wat er in mijn ogen nu niet klopt is dat op OpenStreetMap soortgelijke straten op verschillende manieren worden getagd. Als heel Brussel vol ligt met residentials en heel Amsterdam met unclassifieds - terwijl het om dezelfde soort straten gaat - dan is dat toch niet helder voor de gebruiker? Tja, wat in Brussel (België) normaal is wil niet zeggen dat dat in Nederland normaal is. In België is het blijkbaar normaal om residential area's zo op te splitsen dat wegen altijd buiten een residential area vallen. Levert heel vervelende data op om te bewerken, maar blijkbaar vinden ze dat daar prettig. En nog vervelender: een selectie van wegen binnen een residential area levert in dat geval geen data op. Ik weet niet of daar over nagedacht is. En als je zelf (zoals je hieronder schrijft) dat dus wijzigt, dan is er dus klaarbkijkelijk ook in jouw ogen iets niet in orde met die tagging. Niet helemaal juist wil niet direkt zeggen fout. Als ik ze zelf tegenkom en ik wijzig iets aan de weg (meestal maxspeed) dan verander ik de highway tag ook. Eigenlijk makkelijk: 30 km/h is altijd residential, 50 km/h is vrijwel altijd residential (het kan natuurlijk buiten de bebouwde kom liggen. En wie gaat dat veranderen? Kan dat niet geautomatiseerd worden? Zijn er bezwaren? Bezwaren: wat is er mis en waarom zou je het geautomatiseerd willen veranderen. Ik zou het geautomariseerd willen doen vanwege het grote aantal straten, maar dat stuit op veel te veel bezwaren omdat er dan ten onrechte straten worden gewijzigd die niet gewijzigd mogen worden. Want er zijn wel degelijk straten die met recht UCL hebben binnen de bebouwde kom. Als alle andere tags op de straten correct zouden zijn (zoals bv. de snelheidslimiet) dan zou je nog een filter kunnen maken: If (speedlimit = 30) AND (highway=unclassified) then highway = residential Dat zou je automatisch kunnen doen. Volgens mij is de nederlandse wet gereguleerd genoeg dat 30 km wegen alleen binnen de bebouwde kom mogen liggen. Het probleem met de andere unclassified wegen is dat de AND data een aantal residential area's heeft geimporteerd die qua bebouwing wel als residential gezien kunnen worden maar waar geen bebouwde kom is, laat staan een 30km zone. Maar in de meeste gevallen zijn die andere tags er niet. Mijn conclusie is dan ook: het wordt handwerk. Inderdaad. Maarten ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Welke tags voor straten in de bebouwde kom?
Op 30 nov. 2014, om 18:15 heeft Maarten Deen md...@xs4all.nl het volgende geschreven: Tja, wat in Brussel (België) normaal is wil niet zeggen dat dat in Nederland normaal is. In België is het blijkbaar normaal om residential area's zo op te splitsen dat wegen altijd buiten een residential area vallen. Levert heel vervelende data op om te bewerken, maar blijkbaar vinden ze dat daar prettig. En nog vervelender: een selectie van wegen binnen een residential area levert in dat geval geen data op. Ik weet niet of daar over nagedacht is. Maar daar komt ook een van de zaken naar boven die ik in de osm-chaos zo onhandelbaar vindt. (zo noem ik dat maar even, tegen de tijd dat je alle wiki’s hebt gelezen, ben je 500 jaar verder!) Er bestaat dus geen systeem dat bruikbaar is voor alle kaartgebruikers. Je moet klaarblijkelijk weten hoe de Belgische” (Duitse”, Franse” enz. enz) situatie is, om die kaart te kunnen begrijpen van het betreffende land. Als we spreken over normaal”, dan zou ik nog een keer willen wijzen naar mijn lijstje met steden waarin dit normale” voorkomt, en dan kan ik niet anders dan concluderen dan dat de situatie in Nederland afwijkt. Mij ook goed, maar het maakt het steeds moeilijker om beslissingen te nemen die een betrouwbaar beeld opleveren. Ik heb vrijwel al mijn mapperswerk in Spanje gedaan, en daar wordt over de genoemde zaken weer heel anders gedacht en moeten volledig andere beslissingen worden genomen om bruikbare kaarten op te leveren. Maar in de meeste gevallen zijn die andere tags er niet. Mijn conclusie is dan ook: het wordt handwerk. Inderdaad. Daar zijn we het toch wel allebei over eens! Marc. ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Welke tags voor straten in de bebouwde kom?
2014-11-30 18:15 GMT+01:00 Maarten Deen md...@xs4all.nl: Tja, wat in Brussel (België) normaal is wil niet zeggen dat dat in Nederland normaal is. In België is het blijkbaar normaal om residential area's zo op te splitsen dat wegen altijd buiten een residential area vallen. Levert heel Bedoel je met residential area landuse=residential ? Dit heeft toch niets met bebouwde kom te maken ? 'k ben zelf ook niet zo'n voorstander om vele kleine blokjes landuse=residential te hebben, maar ik maak me er ook niet druk over. Bovendien lijken mij de meeste van die highway=unclassified over wegen in industriegebieden te gaan. Na een eerste vluchtige blik op ene simpele overpass query. Dus vanwaar komt die statement in Brussel zijn er veel unclassified wegen ? Niet alles binnen de Brusselse Ring is woongebied. Ik geef toe dat de Jacob Smitstraat beter als residential zou getagged worden. (toch op het eerste zicht, kleine gebouwen ter grootte van een huis) mvg m ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Forum en mailinglijst: 2 kapiteins op hetzelfde schip?
Op 30 nov. 2014, om 11:30 heeft Gert-Jan van der Weijden gee...@dds.nl het volgende geschreven: hallo lijsters, Op het andere net (http://forum.openstreetmap.org/viewforum.php?id=12) is deze thread inmiddels overgegaan in een vrolijke beschouwing over de geschiedenis van het OSM-(NL)-forum. Een aanrader! Maar als gevolg van de door jou voorgestelde overgang naar het forum ben ik wel meer op de list gaan posten!! :) :) Marc. ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [talk-au] AGRI.openstreetmap.org not working
Still not available. Any update on when it's likely to be back. Cheers Ross On 17/10/14 08:40, Ross Scanlon wrote: Any update on when this will be fixed? Cheers Ross On 10/08/14 23:54, Grant Slater wrote: Hi All, Sorry... Not yet been able to get access to the broken machine. It will remain high on my task list to get it up and running again. Longer term the rest of the sysadmin team are planning to replace faffy with a better more reliable imagery server. / Grant On 10 Aug 2014 12:25, Andrew Harvey andrew.harv...@gmail.com mailto:andrew.harv...@gmail.com wrote: On 6 July 2014 15:30, Grant Slater openstreet...@firefishy.com mailto:openstreet...@firefishy.com wrote: We had a problem with the server (faffy) which runs agri.openstreetmap.org http://agri.openstreetmap.org, it no longer starts up, we were limited on time and were not able to get it up and running again. I will visit the data centre in a week to fix or replace the hardware. I do find the AGRI imagery useful and it would be great if we could access it again. Many thanks for all your effort Grant, hopefully you are able to fix the remaining issues. ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
[OSM-talk-ie] Maps for townland plotting
Could I request 23/43 SW - Buncrana please? KDDA ___ Talk-ie mailing list Talk-ie@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ie
Re: [OSM-talk-ie] Maps for townland plotting
On 30 November 2014 at 20:46, Killyfole and District Development Assocation webmas...@killyfole.org.uk wrote: Could I request 23/43 SW - Buncrana Already uploaded a month ago: http://mapwarper.net/maps/4895 D please? KDDA ___ Talk-ie mailing list Talk-ie@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ie ___ Talk-ie mailing list Talk-ie@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ie
Re: [OSM-talk-ie] Maps for townland plotting
On 28 November 2014 at 20:35, Stephen Roulston srouls...@me.com wrote: Could I request, please, 29/41 (all) http://mapwarper.net/maps?field=titlequery=IRL-GSGS-3906-29-41show_warped=0 and 32/41 - there are just NW and SW in those, I think. Upload 3 sheets - tiny bit on SE as well: http://mapwarper.net/maps?field=titlequery=IRL-GSGS-3906-32-41show_warped=0 D Thanks Stephen_Co_Antrimo ___ Talk-ie mailing list Talk-ie@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ie
[Talk-br] Reversão de changeset que apagou linhas e torres de transmissão.
Bom dia, pessoal. Alguém se opõe a reversão do changeset 27086752 ( http://www.openstreetmap.org/changeset/27086752) do usuário Nina Arboitte ( http://www.openstreetmap.org/user/Nina%20Arboitte)? O usuário somente apagou dados, além de ser um usuário novo com uma edição apenas. Especificamente, apagou linhas de transmissão e torres de energia. http://zverik.osm.rambler.ru/whodidit/?zoom=13lat=-29.88lon=-51.275layers=BTTchangeset=27086752age=187 http://www.itoworld.com/map/4?lon=-51.26592lat=-29.88157zoom=13fullscreen=true Atenciosamente, Claiton Neisse 55 8147 1030 ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Reversão de changeset que apagou linhas e torres de transmissão.
Oi Claiton pode reverter, você sabe fazer o quer que alguém daqui o faça? Gerald 2014-11-30 11:14 GMT-02:00 Claiton Neisse claiton.nei...@gmail.com: Bom dia, pessoal. Alguém se opõe a reversão do changeset 27086752 ( http://www.openstreetmap.org/changeset/27086752) do usuário Nina Arboitte (http://www.openstreetmap.org/user/Nina%20Arboitte)? O usuário somente apagou dados, além de ser um usuário novo com uma edição apenas. Especificamente, apagou linhas de transmissão e torres de energia. http://zverik.osm.rambler.ru/whodidit/?zoom=13lat=-29.88lon=-51.275layers=BTTchangeset=27086752age=187 http://www.itoworld.com/map/4?lon=-51.26592lat=-29.88157zoom=13fullscreen=true Atenciosamente, Claiton Neisse 55 8147 1030 ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Reversão de changeset que apagou linhas e torres de transmissão.
Já reverti, Gerald. Changeset de reversão: 27133700 ( https://www.openstreetmap.org/changeset/27133700). Atenciosamente, Claiton Neisse 55 8147 1030 Em 30 de novembro de 2014 11:58, Gerald Weber gwebe...@gmail.com escreveu: Oi Claiton pode reverter, você sabe fazer o quer que alguém daqui o faça? Gerald 2014-11-30 11:14 GMT-02:00 Claiton Neisse claiton.nei...@gmail.com: Bom dia, pessoal. Alguém se opõe a reversão do changeset 27086752 ( http://www.openstreetmap.org/changeset/27086752) do usuário Nina Arboitte (http://www.openstreetmap.org/user/Nina%20Arboitte)? O usuário somente apagou dados, além de ser um usuário novo com uma edição apenas. Especificamente, apagou linhas de transmissão e torres de energia. http://zverik.osm.rambler.ru/whodidit/?zoom=13lat=-29.88lon=-51.275layers=BTTchangeset=27086752age=187 http://www.itoworld.com/map/4?lon=-51.26592lat=-29.88157zoom=13fullscreen=true Atenciosamente, Claiton Neisse 55 8147 1030 ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Inconsistência na tradução do iD: preset pub x bar
Pronto, traduzi pelo Transifex. 2014-11-28 9:55 GMT-02:00 John Packer john.pack...@gmail.com: Alexandre, não sei com que frequência eles atualizam as traduções do repositório de código do editor, mas acredito que eles devam atualizá-las antes de publicar uma nova versão do iD. Mesmo que uma tradução fosse feita diretamente no repositório, ela só entraria em funcionamento quando a próxima versão do iD fosse publicada, logo creio que seja melhor traduzir diretamente no Transifex. Em 27 de novembro de 2014 21:25, Alexandre Magno Brito de Medeiros alexandre@gmail.com escreveu: Será que fazer o *pull request*, invés de atrapalhar, adiantaria o processo? Eu não sei se o Transifex lida com essa necessidade de sincronia de volta. Caso ele seja capaz disso, sim, o *pull request* adiantaria o processo; muito provavelmente, porque em geral o mantenedor deixa o Transifex acumular alterações ou espera um tempo predeterminado antes de efetivar as traduções. Em 27 de novembro de 2014 20:06, Arlindo Pereira openstreet...@arlindopereira.com escreveu: Bem lembrado. Em 27/11/2014 20:55, John Packer john.pack...@gmail.com escreveu: Só uma coisa: pra realizar traduções no editor iD, em vez de fazer a alteração diretamente no repositório de código, é utilizado a interface web da ferramenta Transifex. Link: https://www.transifex.com/projects/p/id-editor/ ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] tag inexistente
Prezados Senhores, Tentei adicionar um ponto no OSM, mas não achei a tag para Engenheiro , Escritorio de Engenharia ou Construtora. (algo como engineer , office engineering ou construction worker?) Achei tags para outras profissões como architect ou lawyer. Também achei office=architect , office=lawyer ou office=it. Não sei como criar estas novas tags no OSM, referente ao engenheiro. Vcs poderiam ajudar ou me orientar como proceder? (sou novato nesses assuntos do OSM) Grato, Helio Cesar Tomio hcto...@gmail.com ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-de] Osmarender Style für Mapnik
Wie mann man: gegebene Styles von Osmarender für Mapnik verwenden? Gibt es da irgend ein Tool? HowTo? Erfahrungen? Doku? Herzlichen Dank, Makus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osmarender Style für Mapnik
Hallo, Am 2014-11-30 um 12:23 schrieb Markus: Wie mann man: gegebene Styles von Osmarender für Mapnik verwenden? Gibt es da irgend ein Tool? HowTo? Erfahrungen? Doku? Es gibt keinen Konverter für Osmarender-Styles in Mapnik-Stile (egal ob Mapnik2-XML oder CartoCSS oder wasweißichwas). Einer der Gründe ist der grundlegend andere Ansatz den Osmarender zur Erzeugung von Grafiken verwendet hat. Es wäre einfacher und schneller einen optisch ähnlichen Stil für Mapnik als Renderingsoftware nachzubauen. Die von dir gesuchte Doku ist schlicht und einfach die Doku, die beschreibt, wie man Mapnik-Stile baut. Viele Grüße Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gemeinsamer Account
Am 29.11.2014 um 19:35 schrieb Michael Kugelmann: Am 29.11.2014 17:23, schrieb Markus: Das ist die eine Weltm die nichts mit OSM zu tun hat. Inhaltlich wachsen beide Welten zunehmend zusammen. WP nutzt viele OSM-Daten und zeigt OSM-Karten, OSM hat viele WP-Links und zeigt diese auf Karten. Und? * Wikipedia ist die Weltweite Online-Enzyklopädie. * das OSM-Wiki ist das Wiki zur Dokumentation von OSM-Themen. Was hat das mit einer Enzykopädie zu tun? Nichts Dass Wikipedia OSM-Daten nutzt und Inhalte verlinkt werden hat nicht mit dem Arbeitshilfsmittel OSM-Wiki zu tun... Naja, ich fände eine einfache Anmeldung von Leuten aus der Wikipedia zum Bearbeiten der Kartendaten schon gut. Z.B. um Wikipedia-Tags setzen zu können. Mit Wordpress-, Google- und AOL-Account kann ich mich ja schließlich auch bei OSM anmelden. Leider setzt die Wikipedia auf das alternative System von Oauth anstatt auf Open-ID, sodass ich jetzt auch keine einfache Möglichkeit zur Umsetzung sehe. Zudem ist der Anmeldeaufwand verhältnissmäßig klein gegenüber dem Aufwand OSM ansatzweise zu verstehen. Trotzdem sollte alle Einstiegshürden nach Möglichkeit reduziert werden. Grüße Tim Sorry, Michael. ___ 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] Gemeinsamer Account
jedes Mediawiki kann nativ Commons-Dateien als interne Links anzeigen. Um es noch einmal etwas deutlicher zu sagen, da viele es nicht wissen. Ihr könnte Bilder von Wikimedia Commons einfach im OSM Wiki einbinden indem ihr den Dateinamen angebt. Siehe auch hier letzer Punkt: http://www.openstreetmap.org/user/AndiG88/diary/23295 __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] JOSM installieren
Wenn man JOSM installiert mit: https://josm.openstreetmap.de/download/josm.jnlp muss man nach der Anpassung der Einstellungen JOSM neu starten. Dabei komt die Meldung: Programm kann nicht gestartet werden Diese Meldung kann man mit OK wegklicken, dann läuft alles wie gewünscht. Wozu dient diese Meldung? Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osmarender Style für Mapnik
Hallo Michael, herzlichen Dank für die klare Ausage: Es gibt keinen Konverter für Osmarender-Styles in Mapnik-Stile Verstanden. Die von dir gesuchte Doku ist schlicht und einfach die Doku, die beschreibt, wie man Mapnik-Stile baut. Hast Du da einen Link? Wir haben ein paar Objekte, z.B.: - Einstiegstelle für Kajakfahren in den Fluss und ein SVG dazu, - Strecke im Fluss und eine Linienfarbe/stärke dazu, und wollen das auf einem Layer mit Mapnik rendern. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gemeinsamer Account
Hallo Tim, Leider setzt die Wikipedia auf das alternative System von Oauth anstatt auf Open-ID Kann man OAuth und Open-ID parallel implementieren? (hat das unerwünschte Nebenwirkungen? welche?) Falls ja: Wie können wir Wikimedia dazu bewegen, beide Systeme zu bedienen? Falls nein: Wie könnte eine Lösung aussehen? Zudem ist der Anmeldeaufwand verhältnissmäßig klein gegenüber dem Aufwand OSM ansatzweise zu verstehen. Das ist richtig. Für neue Benutzer, die nur einen begrenzten Bereich von OSM nutzen und OSM erst mal nicht in allen Teifen verstehen müssen, (Kajakfahrer beispielsweise) wäre es trotzdem sinnvoll: Trotzdem sollte alle Einstiegshürden nach Möglichkeit reduziert werden. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Screencast-Programm
ich suche ein Screencast-Programm, mit folgenden Fähigkeiten: - getrennte Tonspur - mehrere Bildspuren - Bilder/Video in Screncast einbinden - genaues Schnittprogramm - Zoom im Bild (optional) - Dinge hervorheben - Export nach Youtube - Speichern als Datei (MP4 etc.) - gute Doku (idealerweise deutsch) und natürlich - keine Zeitbeschränkung (mind 15') - keine Werbeeinblendungen - idealerweise kostenlos - vielleicht sogar OpenSource angeschaut habe ich: a) Camtasia 299$ (+++) gut aber teuer b) EZVid (gratis) Schneiden nicht sinnvoll möglich c) Jing (gratis) kein FB-Export Wer hat eine Idee? Mit herzlichem Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Screencast-Programm
Hallo, ein sehr empfehlenswertes Programm ist OBS (OpenBroadcasterSoftware) Du kannst damit alles mögliche einstellen, den Ton in einer externen Spur, (zur Not mit Audacity aufnehmen) Du musst dich da einfach reinfinden und experimentieren. Du kannst da einiges an Quellen einbinden, könntest sogar einen Hintergrund anlegen, wo du dann alles einpasst. Am besten kannst du dieses Programm benutzen, wenn du 2 Monitore hast. Dann kannst du auf dem einen das machen, was du aufnehmen willst und auf dem anderen hast du die Konfiguration an. Gruß Peter Am 30.11.2014 um 17:33 schrieb Markus: ich suche ein Screencast-Programm, mit folgenden Fähigkeiten: - getrennte Tonspur - mehrere Bildspuren - Bilder/Video in Screncast einbinden - genaues Schnittprogramm - Zoom im Bild (optional) - Dinge hervorheben - Export nach Youtube - Speichern als Datei (MP4 etc.) - gute Doku (idealerweise deutsch) und natürlich - keine Zeitbeschränkung (mind 15') - keine Werbeeinblendungen - idealerweise kostenlos - vielleicht sogar OpenSource angeschaut habe ich: a) Camtasia 299$ (+++) gut aber teuer b) EZVid (gratis) Schneiden nicht sinnvoll möglich c) Jing (gratis) kein FB-Export Wer hat eine Idee? Mit herzlichem Gruss, Markus ___ 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-it] DB Topografico Lombardia
2014-11-28 20:30 GMT+01:00 sabas88 saba...@gmail.com: Mio malgrado l'ho visto in diretta, quindi? penso volesse dire di andarci molto piano con gli import, visto che la maggior parte si sono portati dietro problemi -- 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-es] #227 DEL SEMANARIO OSM YA EN ESPAÑOL
Hola El semanario #227 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
Re: [Talk-pt] Malformações nas tiles de Coimbra
Reverti essa edição. ___ Talk-pt mailing list Talk-pt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-pt
[Talk-lv] celju savienojums imantaa
skatos uz sho savienojumu : https://www.openstreetmap.org/#map=19/56.95633/24.00866 peec binga foto izskataas, ka taa patiesiibaa ir ietve. varbuut kaadam ir iespeeja apluukot dabaa :) -- Rich ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv
Re: [Talk-cz] Posunutá mapa?
Ahoj! Záleží, jaký editor byl použit. Mám pocit, že ID a Potlach posunutí vůbec neřeší (teď už možná jo). No a i v JOSM to je docela skryto. Chtělo by to nějak zviditelnit. Třeba mít možnost nastavit vrstvě nějaký příznak a JOSM by při načtení vrstvy automaticky nabídlo kalibraci. Bylo by dobry nejaky reseni, ktery funguje Nejlepsi by bylo, kdyby se ortofoto samo zobrazilo se spravnou kalibraci. A ono... ty silnice (etc) pochazeji z ne vzdy uplne presnych zdroju. GPSky, a importy delany z GPSek.. takze rozeznat co je dobre neni vzdycky snadny. Pokud jsou nekde budovy posunuty.. bylo by mozny je hromadne vzit (select building=...) a posunout na dobry misto? Protoze jinak to bude jen horsi... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Evidence a hlášení špatných budov v RÚIAN
Cau, hezka prace. Dalsi duvod je ten, ze budova uz je zbourana a nestoji. Prosim pridat. Do mapy by se hodilo i pridat vrstvu, kde jdou videt spatne budovy (pro pripadnou kontrolu) a vrstvu, kde budou budovy, ale nezobrazi se ty co jsou chybne(kdyz se resi co chybi dodelat v meste). Dne 30. listopadu 2014 20:00 Petr Vejsada o...@propsychology.cz napsal(a): Ahoj, tak zase jeden víkend strávený nad OSM. Slibuji, že se to už nebude opakovat ;-). Drobné úpravy na poloha.net: - odkazování na ruian.poloha.net je možné i s vrstvami. Formát je z/y/y/layers z = zoom x = šírka y - délka layers: l = landuse i = LPIS p = parcely u = ulice b = budovy t = budovy-todo a = adresy Takže chceme-li odkázat na Nižbor a rozsvítit ulice a budovy, bude odkaz http://ruian.poloha.net/18/50/14/ub Formát z/y/z je stejný jako na OSM serveru. Layers je nepovinné. K dořešení: - měnit URL tak, jak pohybujeme mapou (jako to je na OSM). Kdo by věděl, jak to udělat, ať se ozve nebo nejlépe pošle rovnou patch :-) - rozsvícením vrstev se změní pořadí na selectoru a tedy nabídka je pak v jiném pořadí než default - dtto patch Hlášení špatných budov - pro stroje (třeba odkaz z JOSM traceru ;-))) - http://ruian.poloha.net/building.php?kod= kde je kód stavebního objektu v RÚIAN - pro lidi - kliknutím do mapy na http://ruian.poloha.net - nesmí se tou myší při klikání mrskat, jinak to chápe jako šoupání mapou a ne jako kliknutí. Klikat je vhodné do budovy ;-), jinak to nefunguje. Volby: - důvod - to je jasné, proč je budova špatně. Důvody jsou zatím 2, pište sem další důvody, abych je do menu přidal. - hlásit ČÚZK - jestli si myslíte, že je to na nahlášení na ČÚZK. Zaškrtnout. - poznámka - poznámka Jednou zadaná budova se dá kdykoli opravit či smazat, stačí do ní znovu kliknout. Celá historie se loguje ;-) Mapa se renderuje ihned po zadání či úpravě záznamu (ihned=cca 5 vteřin podle toho, jakou má Mapnik zrovna frontu), jen nevím, jak ji reloadnout či zahodit cache prohlížeče. Budovy, zapsané do tohoto seznamu se vykreslují šedivě. na http://poloha.net jsou u uživatelských účtů kontaktní údaje pro ČÚZK (menu Můj_účet, upravit či tak nějak). Pokud to vyplníte a ČÚZK snad náhodou bude tato hlášení od nás brát, předpokládám, že tyto kontaktní údaje mu předám, tedy nepište tam nic, pokud to nechcete sdílet s ČÚZK. na http://ruian.poloha.net/neplatne-budovy se zobrazuje výstražný trojúhelník v případě, že poté, co byla budova zadána do zdejšího seznamu se v RÚIAN změnila (item_timestamp datum zadání do seznamu). Je to upozornění, že budova mohla být v RÚIAN opravena. Co hlásit a co nehlásit - tím si sám nejsem jistý. Někdy je jako budova celé autobusové nádraží. On je to stavební objekt, ne budova, takže to vlastně může být správně a hlásit by se to nemělo, nebo také mělo, netuším. Pane Součku, pokud to čtete, mám na mysli např. SO 40356272 - autobusové nádraží Praha- Florenc. To je asi správně, ale jistotu nemám.? Dále např. SO 21618861 - bytový dům, ale je včetně nádvoří. To nádvoří ale také může být stavebním objektem. A naposled - domy 24602523 a sousední - tři z těchto domů mají geometrii včetně příjezdové cesty, ostatní jen jako vlastní domy. Je to chyba nebo není? A pro všechny - hlaste chyby. Musíte mít účet na OSM, abyste mohli zadávat chybné budovy. -- Petr, p...@propsychology.cz p ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Evidence a hlášení špatných budov v RÚIAN
Ahoj, díky, důvod přidán, vrstvy - už jich je docela dost, ne? Myslím si, že vrstva todo by měla vyhovovat, co jsou chybné se zobrazují šedivě. Pokud někdo má potíže s rozlišováním barev, dal by se přidat nějaký znak, třeba křížek jako škrtanec. Přidal jsem jako overlay ortofoto a teprve teď mě napadá, jestli se to smí? Víte to někdo? Podle http://geoportal.cuzk.cz/%28S%28css5b5gul5njpblscfb2iyuc%29%29/Default.aspx?menu=3121mode=TextMetaside=wms.verejnemetadataID=CZ-CUZK-WMS-ORTOFOTO-PmetadataXSL=metadata.sluzba je WMS free, ale jestli se to může zabalit do leafletu a nechat volně dostupné přes web? Samotné WMS ve Firefoxu nezobrazím, ? -- Petr Dne Ne 30. listopadu 2014 21:19:10, Radek Kuznik napsal(a): Cau, hezka prace. Dalsi duvod je ten, ze budova uz je zbourana a nestoji. Prosim pridat. Do mapy by se hodilo i pridat vrstvu, kde jdou videt spatne budovy (pro pripadnou kontrolu) a vrstvu, kde budou budovy, ale nezobrazi se ty co jsou chybne(kdyz se resi co chybi dodelat v meste). ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Evidence a hlášení špatných budov v RÚIAN
Ahoj, slušná práce :-) On 30.11.2014 20:00, Petr Vejsada wrote: Hlášení špatných budov - pro stroje (třeba odkaz z JOSM traceru ;-))) - http://ruian.poloha.net/building.php?kod= kde je kód stavebního objektu v RÚIAN PointInfo mi přijde jako lepší místo na proklik. Ale i do Traceru by to šlo, akorát v něm dochází klávesy. Zbývá jen Alt a kombinace s ním. - důvod - to je jasné, proč je budova špatně. Důvody jsou zatím 2, pište sem další důvody, abych je do menu přidal. Postrádám oblíbené useknutí/rozpůlení budovy hranicí parcely. Roztažení budovy přes celou plochu parcely budem počítat za špatnou polohu budovy? Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Evidence a hlášení špatných budov v RÚIAN
Dne 30.11.2014 22:19, Marián Kyral napsal(a): Dne 30.11.2014 21:55, Martin Švec - OSM napsal(a): Ahoj, slušná práce :-) On 30.11.2014 20:00, Petr Vejsada wrote: Hlášení špatných budov - pro stroje (třeba odkaz z JOSM traceru ;-))) - http://ruian.poloha.net/building.php?kod= kde je kód stavebního objektu v RÚIAN PointInfo mi přijde jako lepší místo na proklik. Ale i do Traceru by to šlo, akorát v něm dochází klávesy. Zbývá jen Alt a kombinace s ním. Dodělat to do PointInfo není problém. Nápad na nějakou jednoduchou, ale dostatečně popisnou ikonku? Marián Tak jsem do PointInfa přidal další ikonku. Měl by to být brouček ;-) Během několika minut by se v JOSM měla nabídnout nová verze pluginu. Dobrou, Marián - důvod - to je jasné, proč je budova špatně. Důvody jsou zatím 2, pište sem další důvody, abych je do menu přidal. Postrádám oblíbené useknutí/rozpůlení budovy hranicí parcely. Roztažení budovy přes celou plochu parcely budem počítat za špatnou polohu budovy? Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Posunutá mapa?
Záleží, jaký editor byl použit. Mám pocit, že ID a Potlach posunutí vůbec neřeší (teď už možná jo). Tak ID posunuti umi resit. Otazka spise je, kolik lidi si tim lame hlavu? Ba co hur, kdyz uz si s tim clovek lame hlavu a chce si to posunout, jak pozna spravne posunuti? Podle ceho to srovnat? (To neni jen akademicka otazka, jako prilezitostneho prispevovatele mne fakt zajima, jak to nejlepe srovnat?) -- Lukas Gebauer. http://synapse.ararat.cz/ - Ararat Synapse - TCP/IP Lib. http://geoget.ararat.cz/ - Geocaching solution ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [OSM-talk-fr] Perspective d'établissement de la couverture du sol à partir des images Sentinel 2
Le Sat, 29 Nov 2014 21:36:21 +0100, Yves Pratter yves.prat...@gmail.com a écrit : Le 29 nov. 2014 à 18:35, Jordi Inglada fe...@jordiinglada.net a écrit : Les outils que j'évoque tournent sur des PC standards et quelques heures de calcul suffisent pour traiter une année de données sur une tuile de 100km. Est-il prévu un projet similaire à SETI@home http://fr.wikipedia.org/wiki/SETI@home pour distribuer des calculs ? — Yves J'ai commencé à cartographier les landuse autour de chez moi : http://www.openstreetmap.org/#map=14/48.5410/-4.0340 Dois-je continuer ? Merci ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Perspective d'établissement de la couverture du sol à partir des images Sentinel 2
Le 30/11/2014 11:11, lann a écrit : J'ai commencé à cartographier les landuse autour de chez moi : http://www.openstreetmap.org/#map=14/48.5410/-4.0340 Dois-je continuer ? Oui ! (C'est pas avec une image à 10m qu'on fera mieux qu'avec Bing et sa résolution !) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Perspective d'établissement de la couverture du sol à partir des images Sentinel 2
Bonjour, lann a écrit : J'ai commencé à cartographier les landuse autour de chez moi : http://www.openstreetmap.org/#map=14/48.5410/-4.0340 Superbe travail ! Bravo. Dois-je continuer ? Oui, pour plusieurs raisons : - Le travail que tu as réalisé me semble d'une finesse supérieure à celle que nous pourrons attendre de Sentinel2. - Ni les images Sentinel2 ni les chaines de traitement évoquées par Jordi ne sont pour l'heure disponibles. Et un proverbe dit « un tiens vaut mieux que deux tu l'auras ». Ton travail améliore la carte dès aujourd'hui et inspirera sans doute d'autres contributeurs. - Lorsque les images Sentinel2 et les chaines de traitement associées seront disponibles, les données produites n'invalideront pas ton travail mais permettront au contraire de l'affiner (les séries temporelles permettent d'identifier la nature de la végétation de manière plus fine que ne le permet un seul cliché) et de le mettre à jour (i.e. en constatant par exemple qu'une zone identifiée dans la base OSM comme parcelle agricole est désormais identifiée comme zone urbaine. Sébastien -- Sébastien Dinot, sebastien.di...@free.fr http://sebastien.dinot.free.fr/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Perspective d'établissement de la couverture du sol à partir des images Sentinel 2
Le 30/11/2014 11:28, JB a écrit : Le 30/11/2014 11:11, lann a écrit : J'ai commencé à cartographier les landuse autour de chez moi : http://www.openstreetmap.org/#map=14/48.5410/-4.0340 Dois-je continuer ? Oui ! (C'est pas avec une image à 10m qu'on fera mieux qu'avec Bing et sa résolution !) Surtout que pour l'instant les deux satellites sont encore sur terre. Lancement prévu pour avril 2015 et 2016. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modèle numérique de terrain (MNT) de la Nasa en pas de 30m, bientôt pour tous le monde
Le 30/11/2014 00:20, yvecai a écrit : Vivement la couverture globale ! Yves L'Europe est déjà sortie ? Tu as les liens de téléchargements ? JB ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Perspective d'établissement de la couverture du sol à partir des images Sentinel 2
Salut, JB a écrit : (C'est pas avec une image à 10m qu'on fera mieux qu'avec Bing et sa résolution !) C'est à la fois vrai et faux car il n'y a pas que la résolution spatiale qui compte. 1. La fraicheur de la donnée est capitale. Cartographier finement une zone urbaine à partir d'une image qui a cinq ans revient à tracer une carte erronée. Par exemple, le bâtiment en L qui apparait au centre de l'image ci-dessous est une ancienne fabrique qui a été détruite suite à l'accumulation de neige sur son toit il y a trois ans : http://binged.it/11FalpX Et les bâtiments qui apparaissent sur celle ci-dessous ont été détruits, certains ont été remplacés par un supermarché, d'autres par un parking et un terrain reste en friche à cette date : http://binged.it/1B2H1ZL 2. Il n'est pas toujours évident de déterminer le type de végétation à partir d'une seule image. Avec des séries temporelles, on peut mesurer les propriétés radiométriques du terrain au fil des mois et, par croisement avec des observations de terrain, identifier du blé, une prairie, etc. 3. Une précision extrême entraine parfois un vieillissement accéléré de la carte et peut représenter une déperdition inutile d'énergie. Si par exemple, on se fixe comme objectif de délimiter le contour des forêts à 5 mètres près, le tracé réalisé une année sera probablement « juste » deux ans plus tard (sauf campagne d'abattage). Mais si l'on se fixe comme objectif de délimiter les forêts à 10 cm, le tracé sera faux un mois plus tard (en fait, l'image ayant un certain âge, la carte est déjà fausse au moment de son tracé). Sébastien -- Sébastien Dinot, sebastien.di...@free.fr http://sebastien.dinot.free.fr/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Perspective d'établissement de la couverture du sol à partir des images Sentinel 2
C'est dimanche, je réponds ? - Pour la personne qui cartographie son village puis les environs, je ne pense pas que l'imagerie à 10m apportera grand chose par rapport à Bing ou aux orthos locales. - http://binged.it/11FalpX : C'est pas un peu de la mauvaise foi, là ? Tu vas pas nous faire croire que c'est une image à 10m/pixel, quand même ? Je ne pense pas que la nouvelle source sera très utile pour dessiner des batiments ? - on va vraiment tenir à jour les cultures dans les landuses=farmland tous les ans ? Je sais que certaines personnes se sont essayées aux données issues de la PAC (le parcellaire, il me semble, mais à vérifier), mais vu ce que j'en avais senti, déjà un import est foireux, mais alors si en plus il faut le mettre à jour ! - je ne pense pas non plus que grand monde ait pour objectif de définir les forêts à 10cm. Après, je suis tout à fait d'accord que pour des zones moins développées et HOT, ce sera surement très bien pour déterminer les landuses, notamment résidentiels. JB. Le 30/11/2014 11:56, Sébastien Dinot a écrit : Salut, JB a écrit : (C'est pas avec une image à 10m qu'on fera mieux qu'avec Bing et sa résolution !) C'est à la fois vrai et faux car il n'y a pas que la résolution spatiale qui compte. 1. La fraicheur de la donnée est capitale. Cartographier finement une zone urbaine à partir d'une image qui a cinq ans revient à tracer une carte erronée. Par exemple, le bâtiment en L qui apparait au centre de l'image ci-dessous est une ancienne fabrique qui a été détruite suite à l'accumulation de neige sur son toit il y a trois ans : http://binged.it/11FalpX Et les bâtiments qui apparaissent sur celle ci-dessous ont été détruits, certains ont été remplacés par un supermarché, d'autres par un parking et un terrain reste en friche à cette date : http://binged.it/1B2H1ZL 2. Il n'est pas toujours évident de déterminer le type de végétation à partir d'une seule image. Avec des séries temporelles, on peut mesurer les propriétés radiométriques du terrain au fil des mois et, par croisement avec des observations de terrain, identifier du blé, une prairie, etc. 3. Une précision extrême entraine parfois un vieillissement accéléré de la carte et peut représenter une déperdition inutile d'énergie. Si par exemple, on se fixe comme objectif de délimiter le contour des forêts à 5 mètres près, le tracé réalisé une année sera probablement « juste » deux ans plus tard (sauf campagne d'abattage). Mais si l'on se fixe comme objectif de délimiter les forêts à 10 cm, le tracé sera faux un mois plus tard (en fait, l'image ayant un certain âge, la carte est déjà fausse au moment de son tracé). Sébastien ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Perspective d'établissement de la couverture du sol à partir des images Sentinel 2
JB a écrit : - Pour la personne qui cartographie son village puis les environs, je ne pense pas que l'imagerie à 10m apportera grand chose par rapport à Bing ou aux orthos locales. On ne peut pas faire de généralité, cela dépendra de la sensibilité des contributeurs. Mon propos était de réagir à ton affirmation selon laquelle on ne fera mieux avec une image Sentinel2 (au passage, je m'aperçois que j'ai oublié dans mon précédent message d'appuyer sur la répétabilité). - http://binged.it/11FalpX : C'est pas un peu de la mauvaise foi, là ? Tu vas pas nous faire croire que c'est une image à 10m/pixel, quand même ? Je n'ai jamais dit cela. Je montrais juste que la résolution spatiale n'était pas le seul élément qui faisait l'intérêt d'une image et que sa fraîcheur était un aspect tout aussi important. J'ai pointé l'endroit en question car je le connais et il me permet de dater l'image : elle a plusieurs années (sans doute 5 ans) et cette ville-là s'étend très rapidement. Je ne pense pas que la nouvelle source sera très utile pour dessiner des batiments ? Tout à fait d'accord. Même de l'image SPOT à 2,5 m a un intérêt très limité en la matière. Par contre, ces images permettent de tracer les limites de forêt, de lac, de culture et leur rafraichissement rapide permet d'actualiser la carte plus fréquemment. La fraicheur de la donnée qui nous sert à établir la carte est essentielle. J'habite à Toulouse et le tissu urbain de l'agglomération évolue très rapidement. Nous avons attendu une dizaine de mois l'orthophoto de 2013 et lorsqu'elle est sortie, je la savais déjà obsolète dans plusieurs coins que je connais. La prochaine campagne aura lieu mi-2015 et si Toulouse Métropole et son prestataire n'accélèrent pas leur processus de production et de mise en ligne, nous n'aurons cette image qu'au printemps 2016. C'est long ! - on va vraiment tenir à jour les cultures dans les landuses=farmland tous les ans ? À la main, cet objectif est impossible à tenir. Mais s'il s'appuie sur des données largement prétraitées, il est atteignable. Et sans doute que l'effort ne sera pas fait sur tout le territoire mais si quelqu'un a intérêt à le faire sur une zone donnée, il est bien qu'il puisse le faire. - je ne pense pas non plus que grand monde ait pour objectif de définir les forêts à 10cm. J'espère bien que tu as mieux à faire dans la vie ! C'était pour illustrer mon propos qui peut en choquer certains : l'extrême précision peut nous desservir car elle peut engendrer une surcharge de travail. Sébastien -- Sébastien Dinot, sebastien.di...@free.fr http://sebastien.dinot.free.fr/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Perspective d'établissement de la couverture du sol à partir des images Sentinel 2
Le 30 nov. 2014 à 12:10, JB jb...@mailoo.org a écrit : - on va vraiment tenir à jour les cultures dans les landuses=farmland tous les ans ? Ce qui est intéressant ce sont les mises à jour très fréquentes associées aux logiciels de traitements automatiques. Ces copies d’écran et le petit diaporama montrent ce que ça peut apporter : http://www.orfeo-toolbox.org/otb/slideshowscreenshots.html (à relativiser car les images ont l‘air d’avoir une résolution métrique) Le 29 nov. 2014 à 19:59, Pierre Béland pierz...@yahoo.fr a écrit : Je rêve de modèles de classification automatique qui focusent sur de tels éléments. je crois que c’est possible et à notre portée (manque plus que le lancement des satellites). Quoi que si HOT peut obtenir des images satellites récentes, les logiciels de Jordi sont probablement déjà utilisables (au bémol près que les images Bing ne contiennent pas de bandes infrarouges ce qui sera peu ou pas efficace pour détecter et classifier des cultures). @Jordi, Que peut-on attendre des images Bing avec la boite à outils ? Avoir une image par mois est une temporalité très intéressante dans des zones telles le haut delta du Niger, C’est une image sans nuages ;-) Mais les autres seront effectivement disponibles tous les 5 ou 10j et permettront une utilisation même automatique car elles disposent d’un masque pour ne pas tenir compte des nuages. Sans doute davantage utilie pour certains types de désastre. Tu parles du passage des bulldozer dans la ZAD du Testet ;D — Yves PS: D'autres applications possibles ? observer les pertes énergétiques des bâtiments en travaillant avec la couche infra rouge. pour HOT, repérer la présence humaine dans des villages (points chauds la nuit ou au contraire absence si les habitants ont fui à cause d'Ebola)___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Qualification des erreurs en lien avec FANTOIR
Bonjour, Un cas non prévu: 543953845LPL 9EME DIV INF COLONIALEPlace de la 9e Division d'Infanterie Coloniale Le nom est tout à fait exact, mais à cause du nombre de caractères limités du fichier Fantoir, le rapprochement ne se fait pas. Donat ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Rencontres OSM et WKP à Nantes
Le 29 novembre de 10h à 18h c'était journée portes ouvertes OpenStreetMap et Wikipédia à la Cantine Numérique. Malgré un soleil radieux pour cette 3e rencontre de contributeurs nantais, l'ambiance était fort studieuse. Des visites tout du long de la journée, pour un total estimé à une vingtaine de personnes. Plusieurs ateliers ont animé la journée : * initiation à l'utilisation du site principal et contributions simples avec iD * atelier umap pour créer cartes personnalisées et cartes thématiques * atelier récupération de données et intégration dans QGis * intégration des données relevées le 25 octobre Cette journée OSM et Wikipédia était la dernière de l'année. Nous prévoyons de nous retrouver courant décembre pour définir ensemble la suite à donner : * quelle forme souhaitons-nous donner à ces rencontres : quel lieu, quelle fréquence, quelle durée ? * quel(s) objectif(s) : faire connaître OSM et Wikipédia, initier de nouveaux contributeurs, monter en compétence, organiser des projets comme des carto-parties dans différents quartiers de la métropole nantaise voire dans le reste du département, ... Merci de choisir les dates qui vous conviennent sur ce framadate avant le 7 décembre : https://framadate.org/k6ijg5y7l9zuhnbv. Je confirmerai la date et le lieu le 8 décembre, n'hésitez pas à proposer un lieu ou réclamer un autre horaire. A bientôt, Antoine. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Qualification des erreurs en lien avec FANTOIR
Bonsoir, Le 30/11/2014 20:43, Donat ROBAUX a écrit : Un cas non prévu: 543953845L PL 9EME DIV INF COLONIALE Place de la 9e Division d'Infanterie Coloniale Le nom est tout à fait exact, mais à cause du nombre de caractères limités du fichier Fantoir, le rapprochement ne se fait pas. Il y a bien rapprochement, mais avec un Fantoir... périmé. On a côté Fantoir 2 entrées avec quasi le même nom : - 543953845L PL 9EME DIV INF COLONIALE qui est rapproché côté Cadastre et donne les points bleus sur la carte, et la présence dans la colonne voie avec rapprochement, - 543951432N PL 9E DIV INF COLONIALE qui est référencé par la relation associatedStreet http://www.openstreetmap.org/relation/4129677 mais qui est annulé depuis mars 2009, donc pas retrouvé au moment d'entrer dans BANO. En effet, BANO exclut les Fantoir annulés. Il faudrait dans la relation soit enlever ce code, soit le corriger au profit de l'actuel, pour permettre le rapprochement. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Modèle numérique de terrain (MNT) de la Nasa en pas de 30m, bientôt pour tous le monde
Voilà une bonne nouvelle, ça va mériter quelques tests ! Tout d'abord, j'ai un peu peiné à les trouver, tu confirmes que c'est bien ça : http://e4ftl01.cr.usgs.gov/SRTM/SRTMGL1.003/2000.02.11/ ? au niveau taille ça semble correspondre puisque chaque tuille de 1°x1° prend 9 fois plus de place que le SRTM d'avant. Mais sait-on jamais, j'ai trouvé ça un peu au pif en fouillant leur dépot http ;-) Yves wrote Par contre, sur les zones de relief, ces nouvelles données SRTM sont impressionnantes !! A mon éternelle habitude de râleur français, je ne dirais pas impressionnantes, pour tout dire, je suis même un brin déçu par rapport à ASTER. Dans les vallées alpines, on a beaucoup moins de cet horrible bruit qu'on a avec aster, là, vraiment, que du bon. Par contre, dès qu'on s'approche des falaises montagneuses, c'est toujours pas ça. J'ai l'impression que le problème reste le même qu'avec les 90m de résolution : le nombre important de trous (nuages j'imagine) qui ont été comblés par des algos rapiéçant des morceaux de données de ci de là, mais ça fait pas très réél : Ici les coubes de niveau tous les 10m sur la même zone de montagne (Massif Chartreuse en Isère (38) là ou y'a plein de falaises) entre aster et SRTM GL1 : http://sly.letuffe.org/echange/ Faudrait vraiment pouvoir prendre le meilleur des deux ! -- sly - -- sly, contact direct : sylvain /a\ letuffe o r g http://wiki.openstreetmap.org/wiki/User:Sletuffe -- View this message in context: http://gis.19327.n5.nabble.com/Modele-numerique-de-terrain-MNT-de-la-Nasa-en-pas-de-30m-bientot-pour-tous-le-monde-tp5818323p5825904.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] Qualification des erreurs en lien avec FANTOIR
Bonjour, Le 28/11/2014 10:30, Vincent de Château-Thierry a écrit : J'étais parti sur un affichage à part (pour ne pas répéter toute l'aide à chaque ligne, donc alourdir la page, et avoir peu de latitude de mise en page), mais c'est à voir. Un panneau d'aide est accessible désormais en haut à droite de la page. Il est amené à s'enrichir (légende des 4 colonnes notamment). vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Qualification des erreurs en lien avec FANTOIR
Le 30 novembre 2014 22:20, Vincent de Château-Thierry osm.v...@free.fr a écrit : Bonsoir, Le 30/11/2014 20:43, Donat ROBAUX a écrit : Un cas non prévu: 543953845L PL 9EME DIV INF COLONIALE Place de la 9e Division d'Infanterie Coloniale Le nom est tout à fait exact, mais à cause du nombre de caractères limités du fichier Fantoir, le rapprochement ne se fait pas. Il y a bien rapprochement, mais avec un Fantoir... périmé. On a côté Fantoir 2 entrées avec quasi le même nom : - 543953845L PL 9EME DIV INF COLONIALE qui est rapproché côté Cadastre et donne les points bleus sur la carte, et la présence dans la colonne voie avec rapprochement, - 543951432N PL 9E DIV INF COLONIALE qui est référencé par la relation associatedStreet http://www.openstreetmap.org/relation/4129677 mais qui est annulé depuis mars 2009, donc pas retrouvé au moment d'entrer dans BANO. En effet, BANO exclut les Fantoir annulés. C'est moi qui ait changé le code 543953845L par 543951432N, ce dernier venant des données Open Data de la Communauté Urbaine du Grand Nancy. Question: comment savoir qu'un code Fantoir est périmé-annulé? Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-us] State highway refs (was Re: New I.D Feature)
On 2014-11-29 22:45, Shawn K. Quinn wrote: On Sat, 2014-11-29 at 22:21 -0800, Minh Nguyen wrote: Do any routing engines currently care about prefixes on way refs? From what I've seen so far, most of the map styles that use the ref tag to distinguish route networks will recognize either the state abbreviation, SR, or SH. Some renderers use the prefix to choose a state-specific shield, assuming any unrecognized prefix is for a county route (white rectangle at higher zoom levels). MapQuest only recognizes state/provincial abbreviations. Not that we should place too much stock in individual renderer decisions. :-) OSRM doesn't know that, for example, TX 6 and SH 6 are the same highway. Once upon a time, I'd get directions that had things in them like: Turn right on TX 6 Continue on SH 6 Continue on TX 6 Continue on SH 6 Continue on TX 6 ... etc Granted, OSRM still doesn't handle it gracefully when another highway multiplexes for a stretch, but at least one might be able to figure out which highway one's supposed to stay on when it's ref'd the same across the board. When it's not, it becomes much trickier. That's a good point: it is certainly important that an individual route or road be tagged consistently, both its ref and (to the extent possible) its name, so that routers and tools like Nominatim can aggregate ways into roads. -- m...@nguyen.cincinnati.oh.us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Directional suffixes on roads: yes or no?
Hi Jack, I've been doing an import of addresses and buildings in Fulton County since March (time is limited on my hands, but I'm making progress). Atlanta is, for the most part, done, and I'm currently working in SW Fulton County. Georgia's GIS system has the suffixes in their addresses, so I think it would be beneficial to have the street name with suffix in the main name tag. Howdy, I have a question about how much effort should be put into adding directional suffixes to road names. Many counties around Atlanta have adopted directional suffixes for roads, both in incorporated areas as well as outside city limits. Usually all areas in the county use the same system, with directions denoted NE, SE, NW and SW from some standard point, although some cities tend to ignore the suffixes. Also, signage is inconsistent--some street signs bear the suffix while others on the same street don't. In most cases, the suffix is immaterial, and most people don't use it anyway. Use of it or not won't affect directions most of the time, although I know of a few specific cases where knowing the suffix can be important in finding the right location (is your house 100 Concord Road Southeast or Southwest?). The majority of the Tiger data doesn't include the suffix. So, how much should I worry about the missing suffixes? Should they be included in the main name= tag? Or one of the other *name tags with the unsuffixed name in the name= tag. Because most people don't use the suffix, on some roads I've put the with-suffix name in the name= tag and the unsuffixed one in the short_name= tag, but I'm wondering if I should continue to bother. -jack -- Typos courtesy of fancy auto-spell technology. -- Saikrishna Arcot signature.asc Description: This is a digitally signed message part. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] State highway refs (was Re: New I.D Feature)
On 2014-11-29 22:45, Shawn K. Quinn wrote: On Sat, 2014-11-29 at 22:21 -0800, Minh Nguyen wrote: Do any routing engines currently care about prefixes on way refs? From what I've seen so far, most of the map styles that use the ref tag to distinguish route networks will recognize either the state abbreviation, SR, or SH. Some renderers use the prefix to choose a state-specific shield, assuming any unrecognized prefix is for a county route (white rectangle at higher zoom levels). MapQuest only recognizes state/provincial abbreviations. Not that we should place too much stock in individual renderer decisions. :-) My two cents: I must say that here in California, I've made it a habit to remove the County Route designation (CR) which precedes a ref number in our County Route system. For example, NE2 (a banned-from-OSM former contributor for those unfamiliar with that history) entered ref tags for many G2, N1... county routes as CR G2 and CR N1. That, in my opinion, is so redundant (as G and N and A and S... are well-known multi-county/regional-within-California county highway networks) as to be true clutter. People in California do know (and routing software, renderers... SHOULD know) that A1, G2, N4 and S16 are county routes in a lettered system where each letter represents a cluster of counties...at least in California. Also, while SR (for State Route in California and other states) is still legally correct, I still might change for consistency's sake any SR prefix I see in a highway route relation ref tag to be CA instead. So, while SR 17 is correct, I much prefer CA 17 and will change it to that if I see SR in a California highway route relation ref tag. I agree with what we (as OSM volunteers entering/editing data in our map) now do, as well as what map styles/renderers and routing engines do, as Minh notes above: recognize the state abbreviation, SR or SH. Yes, Michigan still has its M- routes, and I think OSM (both its human editors and software components) should just learn to cope with that (plus perhaps a few other states) as exceptions to this largely (though not completely) applicable rule. I believe we are pretty much there, but we still have edge cases, data in the map and newer contributors who are not completely familiar with these conventions in the USA. Discussing it here helps, though wiki documentation and taginfo data which are consistent across the fifty states is better. SteveA California ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] New I.D Feature
On Sat, Nov 8, 2014 at 3:51 PM, Minh Nguyen m...@nguyen.cincinnati.oh.us wrote: On 2014-11-07 22:35, Greg Morgan wrote: In contrast to the addr:state debate that we are having, I always use addr:country key with the US value. The difference here is that addr:country is an agreed upon ISO standard. To be pedantic, the two-letter state abbreviations are codified in ISO 3166-2: https://en.wikipedia.org/wiki/ISO_3166-2:US The standard covers virtually all of the countries in ISO 3166-1 with alphabetic, numeric, or alphanumeric codes. In the U.S., the codes are instantly recognizable as USPS abbreviations, but I don't know whether the codes elsewhere are as commonly recognizable. Not a Canadian but can confirm the ISO 3166-2:CA abbreviations are immediately recognizable as the standard Canada Post/Postes Canada abbreviations. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] State highway refs (was Re: New I.D Feature)
On 2014-11-30 10:41, stevea wrote: My two cents: I must say that here in California, I've made it a habit to remove the County Route designation (CR) which precedes a ref number in our County Route system. For example, NE2 (a banned-from-OSM former contributor for those unfamiliar with that history) entered ref tags for many G2, N1... county routes as CR G2 and CR N1. That, in my opinion, is so redundant (as G and N and A and S... are well-known multi-county/regional-within-California county highway networks) as to be true clutter. People in California do know (and routing software, renderers... SHOULD know) that A1, G2, N4 and S16 are county routes in a lettered system where each letter represents a cluster of counties...at least in California. Some northwest Ohio counties post shields along section line roads that say A, B, C, etc. So far I've been tagging them like CR A, even though you'd be hard-pressed to find that style anywhere outside of OSM. Instead of reducing ambiguity, I wonder if the CR may cause very mild confusion, for example when a router tells its user to turn onto CR R. Also, while SR (for State Route in California and other states) is still legally correct, I still might change for consistency's sake any SR prefix I see in a highway route relation ref tag to be CA instead. So, while SR 17 is correct, I much prefer CA 17 and will change it to that if I see SR in a California highway route relation ref tag. Yes, usage is different in California. I've only ever seen SR on signage a few times, in rather obscure places. But in Ohio, it's ubiquitous. I agree with what we (as OSM volunteers entering/editing data in our map) now do, as well as what map styles/renderers and routing engines do, as Minh notes above: recognize the state abbreviation, SR or SH. Yes, Michigan still has its M- routes, and I think OSM (both its human editors and software components) should just learn to cope with that (plus perhaps a few other states) as exceptions to this largely (though not completely) applicable rule. I believe we are pretty much there, but we still have edge cases, data in the map and newer contributors who are not completely familiar with these conventions in the USA. Discussing it here helps, though wiki documentation and taginfo data which are consistent across the fifty states is better. My response to anyone who wants more consistency is that route relations are the way forward. They may be painful now but they make the data a lot less subject to interpretation. -- m...@nguyen.cincinnati.oh.us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Tagging a seasonally closed roads with uncertain spring opening
Paper maps handle this with Closed in winter. access=seasonal seems the tagging equivalent. Then, perhaps, if actual dates are announced they could be coded: access:announced_opening=20140501 A router may key off access=seasonal to warn people that a closure date needs to be checked for. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Palmer Motorsports Park...
Eeeh, that's not as far out as, say, Hallett http://www.openstreetmap.org/#map=17/36.22111/-96.59435. Though you might want to fix all those SH and SR refs, can't even tell what state that's supposed to be in without asking Nominatim. On Sun, Nov 16, 2014 at 9:05 PM, Hans De Kryger hans.dekryge...@gmail.com wrote: Wow they really built that in the middle of nowhere. Hopefully mapbox gets some new imagery soon so we can see it to. Awesome job thanks Richard! *Regards,* *Hans* On Sun, Nov 16, 2014 at 2:13 PM, Richard Welty rwe...@averillpark.net wrote: ... is now on the map: https://www.openstreetmap.org/#map=16/42.2360/-72.2444 it won't open until mid summer but the pavement is down and i got 3 1/4 laps of it this morning driving the track centerline with tracklogger on my nexus 7. i also left the new track manager (Charlie was just hired 2 days ago) with a house warming present in the form of a 4 pack of toilet paper. so there's another race track that is in OSM and pretty much nowhere else (i did the new Thompson Road CT course this past summer, and our version is way, way better than what's in Google Maps.) richard -- rwe...@averillpark.net Averill Park Networking - GIS IT Consulting OpenStreetMap - PostgreSQL - Linux Java - Web Applications - Search ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Directional suffixes on roads: yes or no?
Jack, Good question. I come from a local government geographer perspective. I feel that the data should be as authoritative and official as possible with regard to naming. It's simple for a computer algorithm to abbreviate, ignore or omit information, but quite difficult to synthesize missing information. The directional suffix you refer to is officially called a post directional. The Federal Geographic Data Committee definition is, A word following the street name that indicates the directional taken by the thoroughfare from an arbitrary starting point, or the sector where it is located. See section 1.7.2.6 http://www.fgdc.gov/standards/projects/FGDC-standards-projects/street-address/05-11.2ndDraft.CompleteDoc.pdf When you say that most people don't refer to it as such, that can definitely pose a challenge to cartographers. My opinion is to use the full name with the post directional and let map data users (or humans) choose what to ignore. Kindly, Elliott On Sat, Nov 29, 2014 at 23:41 Jack Burke burke...@gmail.com wrote: Howdy, I have a question about how much effort should be put into adding directional suffixes to road names. Many counties around Atlanta have adopted directional suffixes for roads, both in incorporated areas as well as outside city limits. Usually all areas in the county use the same system, with directions denoted NE, SE, NW and SW from some standard point, although some cities tend to ignore the suffixes. Also, signage is inconsistent--some street signs bear the suffix while others on the same street don't. In most cases, the suffix is immaterial, and most people don't use it anyway. Use of it or not won't affect directions most of the time, although I know of a few specific cases where knowing the suffix can be important in finding the right location (is your house 100 Concord Road Southeast or Southwest?). The majority of the Tiger data doesn't include the suffix. So, how much should I worry about the missing suffixes? Should they be included in the main name= tag? Or one of the other *name tags with the unsuffixed name in the name= tag. Because most people don't use the suffix, on some roads I've put the with-suffix name in the name= tag and the unsuffixed one in the short_name= tag, but I'm wondering if I should continue to bother. -jack -- Typos courtesy of fancy auto-spell technology. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] State highway refs (was Re: New I.D Feature)
In Georgia, (almost?) all state roads are signed with the state outline and the highway number, but no GA or Georgia text with it. Occasionally you might see State Road or State Route printed on the sign in addition to the state outline. In some very rural areas, I think there might still be a few un-logoed signs, but probably not many. -jack On November 30, 2014 5:58:53 PM EST, Minh Nguyen m...@nguyen.cincinnati.oh.us wrote: On 2014-11-30 10:41, stevea wrote: My two cents: I must say that here in California, I've made it a habit to remove the County Route designation (CR) which precedes a ref number in our County Route system. For example, NE2 (a banned-from-OSM former contributor for those unfamiliar with that history) entered ref tags for many G2, N1... county routes as CR G2 and CR N1. That, in my opinion, is so redundant (as G and N and A and S... are well-known multi-county/regional-within-California county highway networks) as to be true clutter. People in California do know (and routing software, renderers... SHOULD know) that A1, G2, N4 and S16 are county routes in a lettered system where each letter represents a cluster of counties...at least in California. Some northwest Ohio counties post shields along section line roads that say A, B, C, etc. So far I've been tagging them like CR A, even though you'd be hard-pressed to find that style anywhere outside of OSM. Instead of reducing ambiguity, I wonder if the CR may cause very mild confusion, for example when a router tells its user to turn onto CR R. Also, while SR (for State Route in California and other states) is still legally correct, I still might change for consistency's sake any SR prefix I see in a highway route relation ref tag to be CA instead. So, while SR 17 is correct, I much prefer CA 17 and will change it to that if I see SR in a California highway route relation ref tag. Yes, usage is different in California. I've only ever seen SR on signage a few times, in rather obscure places. But in Ohio, it's ubiquitous. I agree with what we (as OSM volunteers entering/editing data in our map) now do, as well as what map styles/renderers and routing engines do, as Minh notes above: recognize the state abbreviation, SR or SH. Yes, Michigan still has its M- routes, and I think OSM (both its human editors and software components) should just learn to cope with that (plus perhaps a few other states) as exceptions to this largely (though not completely) applicable rule. I believe we are pretty much there, but we still have edge cases, data in the map and newer contributors who are not completely familiar with these conventions in the USA. Discussing it here helps, though wiki documentation and taginfo data which are consistent across the fifty states is better. My response to anyone who wants more consistency is that route relations are the way forward. They may be painful now but they make the data a lot less subject to interpretation. -- m...@nguyen.cincinnati.oh.us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us -- Typos courtesy of fancy auto-spell technology. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
