[OSM-talk-be] codes/query overpass turbo
Beste Voor mijn thesis had ik graag wat data van open street map gehad. Echter kan ik niet aan de codes aan uit. Zou graag voor de provincie Vlaams Brabant de verschillende locaties van gebouwen en de bushaltes willen. Iemand van jullie een idee welke query ik hiervoor het best gebruik? Alvast Bedankt ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] codes/query overpass turbo
Ben nu niet thuis, maar bezorg je straks de nodige info. Jo On Aug 23, 2014 4:30 PM, niels willemot niels.wille...@hotmail.com wrote: Beste Voor mijn thesis had ik graag wat data van open street map gehad. Echter kan ik niet aan de codes aan uit. Zou graag voor de provincie Vlaams Brabant de verschillende locaties van gebouwen en de bushaltes willen. Iemand van jullie een idee welke query ik hiervoor het best gebruik? Alvast Bedankt ___ 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] codes/query overpass turbo
On 23-08-14 16:12, niels willemot wrote:
Beste
Voor mijn thesis had ik graag wat data van open street map gehad.
Echter kan ik niet aan de codes aan uit.
Zou graag voor de provincie Vlaams Brabant de verschillende locaties van
gebouwen en de bushaltes willen.
Hallo Niels,
Alle gebouwen via Overpass is een stevige query afhankelijk van het
aantal gebouwen dat eruit komen, met deze query vind je alleszinds deze
al terug, niet gelimiteerd tot de provincie VL-B, maar wel door een
bounding box.
osm-script output=json timeout=125
union
query type=way
has-kv k=building/
bbox-query {{bbox}}/
/query
query type=node
has-kv k=highway v=bus_stop/
bbox-query {{bbox}}/
/query
/union
print mode=meta/
recurse type=down/
print mode=skeleton order=quadtile/
/osm-script
zie http://overpass-turbo.eu/s/4Ht
Om dit dan te limiteren tot vlaams brabant zoek je de relation ID voor
deze : http://www.openstreetmap.org/relation/58004
Die tel je op bij 36 omdat het een relatie is (zie
http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#Query_for_areas_.28is_in.29
)
Dan krijg je het getal : 3600058004
Die zet je erbij als area-query (vervang dus query)
area-query ref=3600196175/
De result set is wel huge en uw browser zal wss wel moeilijk hebben,
dus als je wil testen, neem dan een relatie van een gemeente, bv 'zemst':
osm-script output=json timeout=125
union
area-query ref=3600196175/
query type=way
has-kv k=building/
/query
query type=node
has-kv k=highway v=bus_stop/
/query
/union
print mode=meta/
recurse type=down/
print mode=skeleton order=quadtile/
/osm-script
http://overpass-turbo.eu/s/4HB
En dan zie je dat het werkt (de result set wordt niet gelimiteerd tot de
bbox deze keer maar door de area bepaald door de relatie.
Veel success met de thesis.
Glenn
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] codes/query overpass turbo
Zucht ... De oplossing hieronder is niet echt optimaal, als ik de bbox
weglaat dan lijkt de result set te groot (405MB), dus er zit nog ergens
iets dat niet juist zit in de query. Ben er 2 keer in geslaagd dit
correct eruit te halen, maar de 3de keer lukt het me niet. (timeout wss).
De bounding box zou geen invloed mogen hebben op die query. maw, niet
helemaal een correct antwoord van mij. Zoek wel even verder.
Glenn
On 23-08-14 17:16, Glenn Plas wrote:
On 23-08-14 16:12, niels willemot wrote:
Beste
Voor mijn thesis had ik graag wat data van open street map gehad.
Echter kan ik niet aan de codes aan uit.
Zou graag voor de provincie Vlaams Brabant de verschillende locaties van
gebouwen en de bushaltes willen.
Hallo Niels,
Alle gebouwen via Overpass is een stevige query afhankelijk van het
aantal gebouwen dat eruit komen, met deze query vind je alleszinds
deze al terug, niet gelimiteerd tot de provincie VL-B, maar wel door
een bounding box.
osm-script output=json timeout=125
union
query type=way
has-kv k=building/
bbox-query {{bbox}}/
/query
query type=node
has-kv k=highway v=bus_stop/
bbox-query {{bbox}}/
/query
/union
print mode=meta/
recurse type=down/
print mode=skeleton order=quadtile/
/osm-script
zie http://overpass-turbo.eu/s/4Ht
Om dit dan te limiteren tot vlaams brabant zoek je de relation ID voor
deze : http://www.openstreetmap.org/relation/58004
Die tel je op bij 36 omdat het een relatie is (zie
http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#Query_for_areas_.28is_in.29
)
Dan krijg je het getal : 3600058004
Die zet je erbij als area-query (vervang dus query)
area-query ref=3600196175/
De result set is wel huge en uw browser zal wss wel moeilijk hebben,
dus als je wil testen, neem dan een relatie van een gemeente, bv 'zemst':
osm-script output=json timeout=125
union
area-query ref=3600196175/
query type=way
has-kv k=building/
/query
query type=node
has-kv k=highway v=bus_stop/
/query
/union
print mode=meta/
recurse type=down/
print mode=skeleton order=quadtile/
/osm-script
http://overpass-turbo.eu/s/4HB
En dan zie je dat het werkt (de result set wordt niet gelimiteerd tot
de bbox deze keer maar door de area bepaald door de relatie.
Veel success met de thesis.
Glenn
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be
--
Everything is going to be 200 OK.
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] codes/query overpass turbo - fixed
Ok, deze doet het wel ok:
osm-script output=json timeout=125
union
query type=way
area-query ref=3600196175/
has-kv k=building/
/query
query type=node
area-query ref=3600196175/
has-kv k=highway v=bus_stop/
/query
/union
union
item/
recurse type=down/
/union
print mode=skeleton order=quadtile/
/osm-script
http://overpass-turbo.eu/s/4HF
Nu vervang je de area ref door 3600058004 en je krijgt de
buildings/haltes van heel vlaams-brabant. Het is nutteloos om dit in
een browser te draaien. Je zal de timeout ook best een stuk naar boven
moeten zetten (of weglaten en default gebruiken) wil je resultaat
krijgen. Het is veel data.
Je zou dit kunnen knippen door dit voor elke child relatie (subarea) van
58004 apart te doen en de resultaten samen te voegen. (het zijn er wel
wat). Zie
ook http://www.openstreetmap.org/relation/2524255 (kijk naar admin
level 7 /of 8 ).
Mvg,
Glenn
On 23-08-14 17:29, Glenn Plas wrote:
Zucht ... De oplossing hieronder is niet echt optimaal, als ik de
bbox weglaat dan lijkt de result set te groot (405MB), dus er zit nog
ergens iets dat niet juist zit in de query. Ben er 2 keer in geslaagd
dit correct eruit te halen, maar de 3de keer lukt het me niet.
(timeout wss).
De bounding box zou geen invloed mogen hebben op die query. maw,
niet helemaal een correct antwoord van mij. Zoek wel even verder.
Glenn
On 23-08-14 17:16, Glenn Plas wrote:
On 23-08-14 16:12, niels willemot wrote:
Beste
Voor mijn thesis had ik graag wat data van open street map gehad.
Echter kan ik niet aan de codes aan uit.
Zou graag voor de provincie Vlaams Brabant de verschillende locaties
van
gebouwen en de bushaltes willen.
Hallo Niels,
Alle gebouwen via Overpass is een stevige query afhankelijk van het
aantal gebouwen dat eruit komen, met deze query vind je alleszinds
deze al terug, niet gelimiteerd tot de provincie VL-B, maar wel door
een bounding box.
osm-script output=json timeout=125
union
query type=way
has-kv k=building/
bbox-query {{bbox}}/
/query
query type=node
has-kv k=highway v=bus_stop/
bbox-query {{bbox}}/
/query
/union
print mode=meta/
recurse type=down/
print mode=skeleton order=quadtile/
/osm-script
zie http://overpass-turbo.eu/s/4Ht
Om dit dan te limiteren tot vlaams brabant zoek je de relation ID
voor deze : http://www.openstreetmap.org/relation/58004
Die tel je op bij 36 omdat het een relatie is (zie
http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#Query_for_areas_.28is_in.29
)
Dan krijg je het getal : 3600058004
Die zet je erbij als area-query (vervang dus query)
area-query ref=3600196175/
De result set is wel huge en uw browser zal wss wel moeilijk hebben,
dus als je wil testen, neem dan een relatie van een gemeente, bv
'zemst':
osm-script output=json timeout=125
union
area-query ref=3600196175/
query type=way
has-kv k=building/
/query
query type=node
has-kv k=highway v=bus_stop/
/query
/union
print mode=meta/
recurse type=down/
print mode=skeleton order=quadtile/
/osm-script
http://overpass-turbo.eu/s/4HB
En dan zie je dat het werkt (de result set wordt niet gelimiteerd tot
de bbox deze keer maar door de area bepaald door de relatie.
Veel success met de thesis.
Glenn
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be
--
Everything is going to be 200 OK.
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk] Detrimental to the OSM database
Il giorno 23/ago/2014, alle ore 04:34, Andreas Vilén andreas.vi...@gmail.com ha scritto: Of course people need to actually check the data they add, but as long as there is aerial imagery and there's no reason to doubt it, There is always reason to doubt it, because it will always be depicting the past and never the present - inherently. This said I agree that some potential problems can be solved with high probability using reasonably recent aerial imagery ;-) I believe map roulette is a overall improvement Cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Detrimental to the OSM database
On 23/08/14 04:43, Russ Nelson wrote: I've checked these using surveys, and the aerial photos are right, and the OSM (actually TIGER) data is bad. Once you've edited a few hundred of these ways, you learn to recognize one of these mis-digitized ways. The key perhaps here is that the source data is what was wrong. Had the material been 'armchair mapped' from the first, then many of these problems would not exist? I object to someone telling me that a road needs 'smoothing' ... it may well have very well mapped source data, and someone who does not know that will be stripping data simply because it does not follow the programmers arbitrarily defined rules. This is DEFINITELY not something that should be rolled out blindly across all countries as certainly ome ARE now adding very fine detail over the top of the originally crude tracing! -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Detrimental to the OSM database
2014-08-23 9:56 GMT+02:00 Lester Caine les...@lsces.co.uk: On 23/08/14 04:43, Russ Nelson wrote: I've checked these using surveys, and the aerial photos are right, and the OSM (actually TIGER) data is bad. Once you've edited a few hundred of these ways, you learn to recognize one of these mis-digitized ways. The key perhaps here is that the source data is what was wrong. Had the material been 'armchair mapped' from the first, then many of these problems would not exist? I object to someone telling me that a road needs 'smoothing' ... it may well have very well mapped source data, and someone who does not know that will be stripping data simply because it does not follow the programmers arbitrarily defined rules. And that is why it is checked by humans, using aerial imagery and not changed by unsupervised software. Armchair tracing roads from aerial images is really helpful, with rare exception of well mapped areas with active community. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Detrimental to the OSM database
On 23/08/14 09:16, Mateusz Konieczny wrote: I object to someone telling me that a road needs 'smoothing' ... it may well have very well mapped source data, and someone who does not know that will be stripping data simply because it does not follow the programmers arbitrarily defined rules. And that is why it is checked by humans, using aerial imagery and not changed by unsupervised software. Armchair tracing roads from aerial images is really helpful, with rare exception of well mapped areas with active community. In some areas we are beyond the aerial imagery so as long as people KNOW that the fine detail they are being shown is wrong then OK, but this may well be well mapped detail not something that actually NEEDS 'smoothing' ... especially when the selection of imagery available does not always line up exactly with one another. I'd rather not see some of the list on maproulette applied to the UK and I'm sure other European countries would feel the same? We have some very fine detail now being mapped and any smoothing algorithm wuold have to be very cleaver not to affect that. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Detrimental to the OSM database
On 23/08/14 09:47, Lester Caine wrote: On 23/08/14 09:16, Mateusz Konieczny wrote: I object to someone telling me that a road needs 'smoothing' ... it may well have very well mapped source data, and someone who does not know that will be stripping data simply because it does not follow the programmers arbitrarily defined rules. And that is why it is checked by humans, using aerial imagery and not changed by unsupervised software. Armchair tracing roads from aerial images is really helpful, with rare exception of well mapped areas with active community. In some areas we are beyond the aerial imagery so as long as people KNOW that the fine detail they are being shown is wrong then OK, but this may well be well mapped detail not something that actually NEEDS 'smoothing' ... especially when the selection of imagery available does not always line up exactly with one another. I'd rather not see some of the list on maproulette applied to the UK and I'm sure other European countries would feel the same? We have some very fine detail now being mapped and any smoothing algorithm wuold have to be very cleaver not to affect that. I've had a look at a few of the 'tasks' flagged by maproulette. The first few were quite normal bends in roads and nothing worth doing, but the next couple were substantially more work, and smoothing was not the problem. The whole area was very poorly mapped, with straight lines for roads and tracks that were substantially more complex. iD was even offering to 'straighten them'. So OK it's flagging up areas that need work, but only by default. Around here finding a straight road is the challenge :) http://openstreetmap.us/iD/release/#background=Bingmap=17.00/-83.15249/36.43657 is the one I'm currently on and leaving as it's impossible to see any detail in iD ... how do people cope with the dark images? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] route=road - What's that all about then?
Hi, Am Donnerstag, den 21.08.2014, 19:20 +0100 schrieb Dave F.: http://ra.osmsurround.org/analyzeRelation?relationId=18159_noCache=on This route relation appears to be just for the B3070. Isn't that a waste of time as it's covered by the ref tags on the ways? I thought route relations were a way to allow tagging of journeys taken over numerous types of ways. Any reason why I shouldn't delete it? They are used to describe infrastructure, too. Currently there are 85000 relations of that kind in the database. (1 in DE, only 100 in UK) Often the type=route route=road have extra tags like operator, full name, wikipedia/data link, ... The relation builds a single object for a specific road http://www.openstreetmap.org/relation/20884 Personally, for roads with lower importance, like the B3070 I wouldn't create extra relations. http://www.openstreetmap.org/relation/18159 In other mails I've seen the ref discussion again. Should it be only on the way or on the relation? While it is redundant to place it on both, it helps to do QA tasks like missing segments, wrong elements, wrong ref, ... Relations are not Categories discussion: Whenever this page is cited I'm wondering how would you identify the specific category with a database request? just my 2 cents. This one looks like a bad relation, anyone likes to delete it? http://www.openstreetmap.org/browse/relation/2621325 Regards Werner (werner2101) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Detrimental to the OSM database
On 23/08/2014 03:49, Andreas Vilén wrote: I have never edited in Great Britain before so I hope I didn't step on any toes, but I have edited in southern Sweden since 2008 and before I started there was barely anything there... Looking at ITO's OSM Mapper, that village hasn't had a local mapper since 2011. There are a few active local mappers in Lincoln, and a couple further west, but most of the edits locally have been made people people adding street names remotely, or correcting geometry errors remotely, so I don't think that anyone locally will object. Cheers, Andy ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] route=road - What's that all about then?
Deleting, deleting... First we should try to understand the meaning, the purpose of any data that has been contributed by someone else that we don't understand. I understand the purpose and meaning of the first two relations. Each of them describe a route, so the type=route / route=road looks ok to me . The second one does not provide much more info than the members already provide, but let's consider it will improve in the future with for example an operator=* tag. For the third one, I don't understand it. It is a big list (collection if your prefer) of roads, and I don't understand the opening_hours tags. What is this supposed to describe ? Does this mean nobody can drive on these roads except during the opening_hours ? 2014-08-23 11:18 GMT+02:00 Werner Hoch werner...@gmx.de: Hi, Am Donnerstag, den 21.08.2014, 19:20 +0100 schrieb Dave F.: http://ra.osmsurround.org/analyzeRelation?relationId=18159_noCache=on This route relation appears to be just for the B3070. Isn't that a waste of time as it's covered by the ref tags on the ways? I thought route relations were a way to allow tagging of journeys taken over numerous types of ways. Any reason why I shouldn't delete it? They are used to describe infrastructure, too. Currently there are 85000 relations of that kind in the database. (1 in DE, only 100 in UK) Often the type=route route=road have extra tags like operator, full name, wikipedia/data link, ... The relation builds a single object for a specific road http://www.openstreetmap.org/relation/20884 Personally, for roads with lower importance, like the B3070 I wouldn't create extra relations. http://www.openstreetmap.org/relation/18159 In other mails I've seen the ref discussion again. Should it be only on the way or on the relation? While it is redundant to place it on both, it helps to do QA tasks like missing segments, wrong elements, wrong ref, ... Relations are not Categories discussion: Whenever this page is cited I'm wondering how would you identify the specific category with a database request? just my 2 cents. This one looks like a bad relation, anyone likes to delete it? http://www.openstreetmap.org/browse/relation/2621325 Regards Werner (werner2101) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] online survey about the OSM community
Hi, If you are at least 18 years of age and speak English, [...] The same message has meanwhile been posted to a whole lot of national OSM mailing lists, with an additional ** apologies for cross-posting ** at the top. If you know it is something that you shouldn't be doing, then sticking an upfront apology at the top doesn't cut it really. This is impolite, and disrespectful. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] route=road - What's that all about then?
On 23/08/2014 10:55, Christian Quest wrote: For the third one, I don't understand it. It is a big list (collection if your prefer) of roads, and I don't understand the opening_hours tags. What is this supposed to describe ? Does this mean nobody can drive on these roads except during the opening_hours ? The clue's in the name, I think - Gritting Priority 1 roads - it's an attempt to capture which roads are gritted when it's icy (which in northern Scotland is most of the year apart from a couple of weeks in July :-) ). I'm not convinced that it's best represented as a route relation - in the West Midlands (who have the most extensive OSM gritting map in the UK, I think) this sort of information is collected as on this way: https://www.openstreetmap.org/way/108519826 Cheers, Andy ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Detrimental to the OSM database
On 8/23/2014 5:20 AM, Lester Caine wrote: http://openstreetmap.us/iD/release/#background=Bingmap=17.00/-83.15249/36.43657 is the one I'm currently on and leaving as it's impossible to see any detail in iD ... how do people cope with the dark images? In iD, select the imagery layer New Misaligned TIGER. The new TIGER won't always be better than the original; check it against visible road to judge its quality.It is often much improved and I use it to map through forested areas. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] online survey about the OSM community
Looking at what they are doing I'd say the information being dug out will be of value to the OSM community and help us understand a little more about the people who add value to the maps. It might even help us on the retention rate and bring the experience of the average mapper up a little. It's also being done fairly professionally and running something like this properly costs money, at least its not OSM money. In an ideal world the way to get a proper random sample would be to select OSM mappers randomly then message them. Hopefully you'd get better than 90% response rate to keep it statistically meaningful. Reality is you might be lucky to obtain a 2% response. So the next best thing is OSM-talk and hopefully he'll get the 1,000 responses which he needs to make it statistically meaningful. He didn't get that many responses from the OSM-talk message. OSM-talk is bias in that we don't have that many average mappers here, the national OSM mailing lists have more so it makes sense to make the request to a larger audience. OSM is difficult in that it crosses so many cultural boundaries but in this case I think the cross posting was reasonable to obtain the desired number of respondents. How would you suggest he obtained a large enough random sample? Thanks Cheerio John On 23 August 2014 06:05, Frederik Ramm frede...@remote.org wrote: Hi, If you are at least 18 years of age and speak English, [...] The same message has meanwhile been posted to a whole lot of national OSM mailing lists, with an additional ** apologies for cross-posting ** at the top. If you know it is something that you shouldn't be doing, then sticking an upfront apology at the top doesn't cut it really. This is impolite, and disrespectful. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] online survey about the OSM community
Studies and surveys are interesting for a better understanding of our community, but I'm a bit afraid that the results of this one will be highly biased by one single thing: language. OSM is already very english centric and having a survey that is only available in english won't help understand the OSM community worldwide, just a part of it. It would be interesting to have the same survey being done in another language and compare the results... 2014-08-23 14:48 GMT+02:00 john whelan jwhelan0...@gmail.com: Looking at what they are doing I'd say the information being dug out will be of value to the OSM community and help us understand a little more about the people who add value to the maps. It might even help us on the retention rate and bring the experience of the average mapper up a little. It's also being done fairly professionally and running something like this properly costs money, at least its not OSM money. In an ideal world the way to get a proper random sample would be to select OSM mappers randomly then message them. Hopefully you'd get better than 90% response rate to keep it statistically meaningful. Reality is you might be lucky to obtain a 2% response. So the next best thing is OSM-talk and hopefully he'll get the 1,000 responses which he needs to make it statistically meaningful. He didn't get that many responses from the OSM-talk message. OSM-talk is bias in that we don't have that many average mappers here, the national OSM mailing lists have more so it makes sense to make the request to a larger audience. OSM is difficult in that it crosses so many cultural boundaries but in this case I think the cross posting was reasonable to obtain the desired number of respondents. How would you suggest he obtained a large enough random sample? Thanks Cheerio John On 23 August 2014 06:05, Frederik Ramm frede...@remote.org wrote: Hi, If you are at least 18 years of age and speak English, [...] The same message has meanwhile been posted to a whole lot of national OSM mailing lists, with an additional ** apologies for cross-posting ** at the top. If you know it is something that you shouldn't be doing, then sticking an upfront apology at the top doesn't cut it really. This is impolite, and disrespectful. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] online survey about the OSM community
On Saturday 23 August 2014, john whelan wrote: Looking at what they are doing I'd say the information being dug out will be of value to the OSM community and help us understand a little more about the people who add value to the maps. It might even help us on the retention rate and bring the experience of the average mapper up a little. It's also being done fairly professionally and running something like this properly costs money, at least its not OSM money. So the aims justify the means? Sorry - but no, if you cannot do something in a decent manner you can't do it at all. How would you suggest he obtained a large enough random sample? With voluntary participation you can't, no matter what you do. That's why a census generally is not voluntary. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] online survey about the OSM community
On 23/08/2014, john whelan jwhelan0...@gmail.com wrote: In an ideal world the way to get a proper random sample would be to select OSM mappers randomly then message them. Hopefully you'd get better than 90% response rate to keep it statistically meaningful. Reality is you might be lucky to obtain a 2% response. So the next best thing is OSM-talk and hopefully he'll get the 1,000 responses which he needs to make it statistically meaningful. Remember that we're sending emails and that the task can be automated, so a 2% response rate isn't really an issue. And it's much better to individually contact a uniformly random sample than to globally contact a biased sample (only a particular kind of contributor follows mailing lists). As a added bonus of contacting individually, you already know the person's mapping profile. Here are a few proposed guidelines to keep things in check though : * treat a survey like an import: it should be community-reviewed and accepted before going ahead. Be transparent, be usefull, be well writen, be multilingual, etc. * set target request and response counts ahead of time, and stop sending requests whenever one of the counts is reached * provide a way to opt-out any future survey via you osm account Any other do's and don't ? ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] route=road - What's that all about then?
I have seen park roads that were accessible to the public only during specified daylight hours. Using them after park closing time would likely lead to trespassing charges. So, an opening_hours tag on those roadways would make sense. On August 23, 2014 4:55:15 AM CDT, Christian Quest cqu...@openstreetmap.fr wrote: Deleting, deleting... First we should try to understand the meaning, the purpose of any data that has been contributed by someone else that we don't understand. I understand the purpose and meaning of the first two relations. Each of them describe a route, so the type=route / route=road looks ok to me . The second one does not provide much more info than the members already provide, but let's consider it will improve in the future with for example an operator=* tag. For the third one, I don't understand it. It is a big list (collection if your prefer) of roads, and I don't understand the opening_hours tags. What is this supposed to describe ? Does this mean nobody can drive on these roads except during the opening_hours ? 2014-08-23 11:18 GMT+02:00 Werner Hoch werner...@gmx.de: Hi, Am Donnerstag, den 21.08.2014, 19:20 +0100 schrieb Dave F.: http://ra.osmsurround.org/analyzeRelation?relationId=18159_noCache=on This route relation appears to be just for the B3070. Isn't that a waste of time as it's covered by the ref tags on the ways? I thought route relations were a way to allow tagging of journeys taken over numerous types of ways. Any reason why I shouldn't delete it? They are used to describe infrastructure, too. Currently there are 85000 relations of that kind in the database. (1 in DE, only 100 in UK) Often the type=route route=road have extra tags like operator, full name, wikipedia/data link, ... The relation builds a single object for a specific road http://www.openstreetmap.org/relation/20884 Personally, for roads with lower importance, like the B3070 I wouldn't create extra relations. http://www.openstreetmap.org/relation/18159 In other mails I've seen the ref discussion again. Should it be only on the way or on the relation? While it is redundant to place it on both, it helps to do QA tasks like missing segments, wrong elements, wrong ref, ... Relations are not Categories discussion: Whenever this page is cited I'm wondering how would you identify the specific category with a database request? just my 2 cents. This one looks like a bad relation, anyone likes to delete it? http://www.openstreetmap.org/browse/relation/2621325 Regards Werner (werner2101) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk -- Christian Quest - OpenStreetMap France ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk -- John F. Eldredge -- j...@jfeldredge.com Darkness cannot drive out darkness; only light can do that. Hate cannot drive out hate; only love can do that. Dr. Martin Luther King, Jr.___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] online survey about the OSM community
On 23.08.2014 15:17, Christian Quest wrote: OSM is already very english centric and having a survey that is only available in english won't help understand the OSM community worldwide, just a part of it. It would be interesting to have the same survey being done in another language and compare the results... Understanding the US part might be of great interest already. I recently finished watching the recordings of the SotM US conference which was held earlier this year. My impression is that OSM in the US is dominated by businesses who see OSM as a way to make money. Some give back quite much in the sense of tools and services, but still: It's done by paid community members. Where are the mappers who are not employed by a company using OSM or are using OSM for their freelance work? Where are the altruistic mappers who do the actual work of mapping? I for myself don't get paid for participating in OSM nor do I participate in OSM for making some business. In fact I'm paining money to partiipate in addition to my time invested. My impression is that many of the European OSM projects adn contributors belong into this category. So having some research done what is actually driving mappers in the US is certainly of great interest. First impression might be that it's a lot more money driven over there. Ever heard of getting some monetary reward for working on any of the European quality tools like OSM inspector or osmose? In the US you are mapping for winning a price (see telenav contest) I'm highly interested in the results of the survey. Given the focus of many questions in the survey it might provide answers to this specific question. Stephan ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] online survey about the OSM community
Hum, I was finally curious of what I would find there. I find this: It is important that OpenStreetMap keep the use of maps non-commercial. Is this really a serious question, or a serious survey, or am I just completly mistaking about OSM since the beginning, or is my English not as good as I thought it was? Sorry for the interruption, JB. Le 23/08/2014 15:48, moltonel 3x Combo a écrit : On 23/08/2014, john whelan jwhelan0...@gmail.com wrote: In an ideal world the way to get a proper random sample would be to select OSM mappers randomly then message them. Hopefully you'd get better than 90% response rate to keep it statistically meaningful. Reality is you might be lucky to obtain a 2% response. So the next best thing is OSM-talk and hopefully he'll get the 1,000 responses which he needs to make it statistically meaningful. Remember that we're sending emails and that the task can be automated, so a 2% response rate isn't really an issue. And it's much better to individually contact a uniformly random sample than to globally contact a biased sample (only a particular kind of contributor follows mailing lists). As a added bonus of contacting individually, you already know the person's mapping profile. Here are a few proposed guidelines to keep things in check though : * treat a survey like an import: it should be community-reviewed and accepted before going ahead. Be transparent, be usefull, be well writen, be multilingual, etc. * set target request and response counts ahead of time, and stop sending requests whenever one of the counts is reached * provide a way to opt-out any future survey via you osm account Any other do's and don't ? ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] online survey about the OSM community
It is important that OpenStreetMap keep the use of maps non-commercial. Either the survey doesn't understand about OSM or since it does have a subject matter specialist on board I'd be inclined to think its surveying the perception of the mappers. I strongly suspect many think it is totally non-commercial and I've seen a number of businesses who didn't realise they could use the maps without payment. Cheerio John On 23 August 2014 10:14, JB jb...@mailoo.org wrote: Hum, I was finally curious of what I would find there. I find this: It is important that OpenStreetMap keep the use of maps non-commercial. Is this really a serious question, or a serious survey, or am I just completly mistaking about OSM since the beginning, or is my English not as good as I thought it was? Sorry for the interruption, JB. Le 23/08/2014 15:48, moltonel 3x Combo a écrit : On 23/08/2014, john whelan jwhelan0...@gmail.com wrote: In an ideal world the way to get a proper random sample would be to select OSM mappers randomly then message them. Hopefully you'd get better than 90% response rate to keep it statistically meaningful. Reality is you might be lucky to obtain a 2% response. So the next best thing is OSM-talk and hopefully he'll get the 1,000 responses which he needs to make it statistically meaningful. Remember that we're sending emails and that the task can be automated, so a 2% response rate isn't really an issue. And it's much better to individually contact a uniformly random sample than to globally contact a biased sample (only a particular kind of contributor follows mailing lists). As a added bonus of contacting individually, you already know the person's mapping profile. Here are a few proposed guidelines to keep things in check though : * treat a survey like an import: it should be community-reviewed and accepted before going ahead. Be transparent, be usefull, be well writen, be multilingual, etc. * set target request and response counts ahead of time, and stop sending requests whenever one of the counts is reached * provide a way to opt-out any future survey via you osm account Any other do's and don't ? ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] route=road - What's that all about then?
Am 23.08.2014 15:53, schrieb John F. Eldredge: I have seen park roads that were accessible to the public only during specified daylight hours. Using them after park closing time would likely lead to trespassing charges. So, an opening_hours tag on those roadways would make sense. access:conditional= no @ (sunset-sunrise) or foot:conditional= no @ (sunset-sunrise) depending on other access restrictions. cu colliar signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] online survey about the OSM community
Ok, then it is the last option, my english is not good enough for this survey. But in this case, I suspect it will also be the case for many many other non-english people… Of course people should be able to make money out of OSM. But as pointed out previously, in some countries, it seems that OSM only evolves where money is involved. Anyway, thanks for the explanation. JB. Le 23/08/2014 16:45, john whelan a écrit : It is important that OpenStreetMap keep the use of maps non-commercial. Either the survey doesn't understand about OSM or since it does have a subject matter specialist on board I'd be inclined to think its surveying the perception of the mappers. I strongly suspect many think it is totally non-commercial and I've seen a number of businesses who didn't realise they could use the maps without payment. Cheerio John On 23 August 2014 10:14, JB jb...@mailoo.org mailto:jb...@mailoo.org wrote: Hum, I was finally curious of what I would find there. I find this: It is important that OpenStreetMap keep the use of maps non-commercial. Is this really a serious question, or a serious survey, or am I just completly mistaking about OSM since the beginning, or is my English not as good as I thought it was? Sorry for the interruption, JB. Le 23/08/2014 15:48, moltonel 3x Combo a écrit : On 23/08/2014, john whelan jwhelan0...@gmail.com mailto:jwhelan0...@gmail.com wrote: In an ideal world the way to get a proper random sample would be to select OSM mappers randomly then message them. Hopefully you'd get better than 90% response rate to keep it statistically meaningful. Reality is you might be lucky to obtain a 2% response. So the next best thing is OSM-talk and hopefully he'll get the 1,000 responses which he needs to make it statistically meaningful. Remember that we're sending emails and that the task can be automated, so a 2% response rate isn't really an issue. And it's much better to individually contact a uniformly random sample than to globally contact a biased sample (only a particular kind of contributor follows mailing lists). As a added bonus of contacting individually, you already know the person's mapping profile. Here are a few proposed guidelines to keep things in check though : * treat a survey like an import: it should be community-reviewed and accepted before going ahead. Be transparent, be usefull, be well writen, be multilingual, etc. * set target request and response counts ahead of time, and stop sending requests whenever one of the counts is reached * provide a way to opt-out any future survey via you osm account Any other do's and don't ? ___ talk mailing list talk@openstreetmap.org mailto:talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org mailto:talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] online survey about the OSM community
On 23.08.2014 16:14, JB wrote: Hum, I was finally curious of what I would find there. I find this: It is important that OpenStreetMap keep the use of maps non-commercial. Is this really a serious question, or a serious survey, or am I just completly mistaking about OSM since the beginning, or is my English not as good as I thought it was? I consider this question quite clear. Is it of importance to you that OSM is focusing on non-commercial use. What could be alternatives? OSMF itself could try to monetize maps. 3rd party companies could monetize OSM more than currently. It's about your opinion. How important is the non-commercial aspect of a community project (here: OSM) to you? This is not about the OSM license. Stephan ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Detrimental to the OSM database
On Sat, Aug 23, 2014 at 2:20 AM, Lester Caine les...@lsces.co.uk wrote: http://openstreetmap.us/iD/release/#background=Bingmap=17.00/-83.15249/36.43657 is the one I'm currently on and leaving as it's impossible to see any detail in iD ... how do people cope with the dark images? Lester, I believe you can lighten the image in iD. Just select the layers icon on the right side and select the level of brightness you desire. -- @osm_seattle osm_seattle.snowandsnow.us OpenStreetMap: Maps with a human touch ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Detrimental to the OSM database
Dave, You are challenging the existence of an established set of tools in the OpenStreetMap community with your hunches, so the burden of proof is on you. But I’ll at least debunk your assertions, please see below. -- Martijn van Exel MapRoulette gets help to some of the remote, forgotten places. If they're that remote do they need helping. Who's going to go there? again prove the edits in those locations are accurate genuine. If ‘who’s going to go there’ would guide the decision to make a map of it, we as a project as well as the world at large would be in a very bad place. OK. First random from your site: http://maproulette.org/#t=IT_WaterCrossings/IT_RXING_11.333811432368_43.474069354879 How can anyone who doesn't live in area (I tried to copy/paste the location but the info box disappeared!) possibly know which is correct? The question is not ‘which is correct’. The challenge proposes there might be an incorrect situation as a waterway and a highway cross without having a bridge or tunnel tag. This is all right there in the description: https://dl.dropboxusercontent.com/u/187922/Screenshot%202014-08-23%2009.27.02.png The reason why this is a great MapRoulette challenge is that in most cases, you would be able to resolve this just from looking at Bing imagery. Here is another situation from the same MapRoulette challenge: https://dl.dropboxusercontent.com/u/187922/Screenshot%202014-08-23%2009.30.30.png In the case you point out, the situation is obscured by tree cover: https://dl.dropboxusercontent.com/u/187922/Screenshot%202014-08-23%2009.22.37.png For those situations, you can just skip over the case: https://dl.dropboxusercontent.com/u/187922/Screenshot%202014-08-23%2009.22.47.png http://maproulette.org/#t=osmose-8170-147-soccer/osmose-8170-147-soccer-None-d19295cc3e005283ae80b66bde86f474 Supposed missing soccer pitch in France. I mean, really? Yes, there is. Just look at the aerial imagery. If you don’t know what a soccer pitch looks like, this challenge is not for you. Pick something else. Were you going to make a point about this? https://dl.dropboxusercontent.com/u/187922/Screenshot%202014-08-23%2009.23.28.png___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] online survey about the OSM community
We understand that as a member of multiple lists some OSM contributors may have received the survey invitation more than once and that may have felt like a disrespectful attempt to impose on ones personal time and inbox space. That was definitely not our intent and although we tried to be judicious in our use of national mailing lists (where we only posted in about 10% of the lists), it is difficult to completely avoid duplicate invites to some members. Simply posting the message on talk pages without having it mailed to members seems not to be an available option in the current OSM list setup. The research we are pursuing is, we believe, of interest and its insights helpful to the OSM community in terms of understanding several issues that can help its organizational functioning and mission accomplishment (they address member perceptions, behavior, and profile). Numerous OSM members have been extremely supportive of our work and virtually all of the survey takers show an interest in learning about the findings at the conclusion of the research, a fact that suggests there is value in this research. Yet in order to obtain statistically meaningful results, a certain number of responses is required and we have frankly not reached it yet (hence the renewed request for participation in some national lists). Rather than resigning ourselves to the thought that voluntary participation is impossible to induce (which would largely suggest academic research to be a futile endeavor), we choose to believe that, given the opportunity, enough people will see the value of such research and sacrifice some personal time for the greater good (a behavior that we believe is not foreign to the OSM contributor base). However, to reduce the irritation that apparently these invite messages can produce, we have limited the number of lists approached and will close the survey as planned at the end of August, regardless of the number of responses we will have received. There are clearly things that could be improved about this work we agree, for example, that offering the survey in multiple languages would help obtain more globally representative samples and insights. Yet in most academic research the tradeoff between ideal methodology and resource limitations is a salient concern, and that is definitely the case here. Finally, it is even the exchanges noted on the talk pages and the [limited] negative feedback we have received that help us learn about how the community works internally and interacts with the outside world we are thankful for all the interested members feedback. To the others, we apologize (again). ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] online survey about the OSM community
On Sat, Aug 23, 2014 at 10:51 AM, OSMR osm_resea...@mail.com wrote: We understand that as a member of multiple lists some OSM contributors may have received the survey invitation more than once and that may have felt like a disrespectful attempt to impose on one's personal time and inbox space. That was definitely not our intent and although we tried to be judicious in our use of national mailing lists (where we only posted in about 10% of the lists), it is difficult to completely avoid duplicate invites to some members. Simply posting the message on talk pages without having it mailed to members seems not to be an available option in the current OSM list setup. So many of are frustrated by the limitations of our internal messaging system. But if it were open to just anyone, our system administrator would spend there valuable time blocking individuals that spammed us. The research we are pursuing is, we believe, of interest and its insights helpful to the OSM community in terms of understanding several issues that can help its organizational functioning and mission accomplishment (they address member perceptions, behavior, and profile). Numerous OSM members have been extremely supportive of our work and virtually all of the survey takers show an interest in learning about the findings at the conclusion of the research, a fact that suggests there is value in this research. Yet in order to obtain statistically meaningful results, a certain number of responses is required and we have frankly not reached it yet (hence the renewed request for participation in some national lists). Rather than resigning ourselves to the thought that voluntary participation is impossible to induce (which would largely suggest academic research to be a futile endeavor), we choose to believe that, given the opportunity, enough people will see the value of such research and sacrifice some personal time for the greater good (a behavior that we believe is not foreign to the OSM contributor base). However, to reduce the irritation that apparently these invite messages can produce, we have limited the number of lists approached and will close the survey as planned at the end of August, regardless of the number of responses we will have received. Many of us would like to see more research on the OSM community to help us develop better way to communicate and identify areas of both improvement and strengths. To that end, I like we'd like to be more of a partner in your project rather than just being the subject. It is not surprising that a large number of people completed the survey. By contributing to OSM we are by nature a sharing group. But many of us would like more in return. It would be nice to explain up front what the survey will return to us. Will we be able to analyze the results? Will we have access to the data? Please note, that we give you free and ready access to all of our data. There are clearly things that could be improved about this work – we agree, for example, that offering the survey in multiple languages would help obtain more globally representative samples and insights. Yet in most academic research the tradeoff between ideal methodology and resource limitations is a salient concern, and that is definitely the case here. Yes, multiple languages should be a high priority. I don't have the numbers, but I suspect we have a very large percentage that are not English speakers. The iD editor has well over 10 languages. I suspect that no focus group was used to test the survey or you might have discovered that we didn't like sections of the survey. Finally, it is even the exchanges noted on the talk pages and the [limited] negative feedback we have received that help us learn about how the community works internally and interacts with the “outside world” – we are thankful for all the interested members’ feedback. To the others, we apologize (again). I'd like to suggest that instead of being the outside world that you become a member of our community. One that provides research that helps us improve. Not everyone in our community is a mapper, they contribute in other ways. Research would be a valuable addition. Thanks for listening, Clifford -- @osm_seattle osm_seattle.snowandsnow.us OpenStreetMap: Maps with a human touch ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] route=road - What's that all about then?
Il giorno 23/ago/2014, alle ore 15:53, John F. Eldredge j...@jfeldredge.com ha scritto: So, an opening_hours tag on those roadways would make sense. conditional access based on time would maybe be more suitable for roads cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] online survey about the OSM community
clickhole.com has reported that a Local Mapper has responded to misguided surveys by deleting the campus data of the offending institution and replacing it with amenity=kindergarten. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] route=road - What's that all about then?
On Thu, 21 Aug 2014 19:20:06 +0100 Dave F. dave...@madasafish.com wrote: http://ra.osmsurround.org/analyzeRelation?relationId=18159_noCache=on This route relation appears to be just for the B3070. Isn't that a waste of time as it's covered by the ref tags on the ways? I thought route relations were a way to allow tagging of journeys taken over numerous types of ways. Any reason why I shouldn't delete it? IIRC route=road relations were suggested to fix the problem of multiplexing (two or more numbered routes sharing the same physical road). In this instance the B3070 appears to be a route between Wareham and Lulworth Cove which multiplexes with the A352 at Worgret Hill. Simply doing an Overpass query for ref=B3070 would be insufficient to return all of the ways required to traverse the route from start to finish, hence the need for a relation. Ironically the the only section currently missing from the relation (the A352) is the bit that makes the relation necessary! -- Regards, Andy Street ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] route=road - What's that all about then?
On Thu, 21 Aug 2014 23:09:40 +0100
SomeoneElse li...@mail.atownsend.org.uk wrote:
On 21/08/2014 22:36, Janko Mihelić wrote:
This makes sense because you can have more than one route on
one way.
Some countries do this, but the UK (where the B3070 is) does not*, so
there's really no need for it.
That's not strictly true, we do multiplex routes but individual
sections of road are only ever referred to by a single route number
(usually the most significant route being carried by the road).
--
Regards,
Andy Street
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Detrimental to the OSM database
Well, I have to admit, I've only seen one problem with the armchair mapping with the smoothing in my local area of Pittsburgh, PA so far. What happened was a long time ago, I cleanup up US-19 and separated segments that were divided and segments that had a 'Center Turn Lane' and tagged as such. Well, it seems that MapRoulette happened to flag one of the segments where it transitioned from divided highway to un-divided w/ a Center Turn Lane and then back to divided for another major intersection. The imagery in Bing clearly showed that there was a Center Turn Lane there and I had he un-divided segment tagged as such. Instead of it being marked as a 'false positive' on the MapRoulette site, the user twinned this segment, even when the Bing imagery didn't justified it (Changeset 22050738 [1]). (And yes, the imagery right now in Bing is still the same as when the change was made.) When I discovered this, I promptly reverted that changeset in Changeset 22262496 [2]. So, as you can see, there are still a few flaws in the MapRoulette smoothing challenge. And unfortunately, not everybody seems to acknowledge that there might be a false positive here and there and mark it as such. Maybe a stronger warning could be given, but I don't know. All I do know is that any time there is a 'Center Turn Lane' on a highway here in the USA, it stays as a single way and only becomes divided is when there is a physical item dividing the highway like a concrete divider. Maybe this particular flag could have been avoided where it wouldn't flag one-way roads merging into a single way if the angle wasn't like a ~90 degree turn or larger as everything is the same right now as when it was unfortunately falsely 'smoothed'. Any thought how this might be avoided in the future Martijn? -James [1] - https://www.openstreetmap.org/changeset/22050738 [2] - https://www.openstreetmap.org/changeset/22262496 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-br] Coletar fotos para o Mapillary de byke ou moto
Oi Alexandre, obrigado pelo incentivo. Vou fazer isto sim, mas já descobri que a correlação GPS que faço no digikam não é suficiente pois falta colocar a direção em que a foto foi tirada (GPSImgDirection). Vou estudar o link que o Arlindo me passou e depois dou notícias na medida que as fotos ficarem disponíveis. Descobri um jeito quase trivial de embutir toda a informação necessária nas fotos tiradas na GoPro para o Mapillary: exiftool -geosync=-1:07 -geotag track.gpx pasta ou seja o próprio exiftool tem uma interface perfeita. Aqui -geosync ajusta o atraso entre imagem e tracklog, -geotag track.gpx especifica o tracklog (aceita numerosos formatos) e pasta é a localização das fotos. abraço Gerald ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-in] online survey (academic research) about the OSM community
***apologies for cross-posting*** Dear OSM contributor, If you are at least 18 years of age and speak English, you are invited to take part in an online survey about the OSM community pursued by faculty at San Diego State University (contact info below). In this academic research, we are trying to understand what makes a highly diverse and dispersed group of individuals come together in the process of co-creation and what types of individuals tend to contribute to OSM. A similar project was pursued several years ago by Nama Budhathoki, PhD (seehttp://wiki.openstreetmap.org/wiki/Research), who is also involved in this research as we try to determine if and how contributor motivations may change over time as the community grows in numbers and expertise. You will be offered the opportunity to receive the overall results of the research project at its conclusion. The entire survey should take about 20 minutes and is completely anonymous. At the end of the survey, you have the option to provide an email address to be entered in a lottery for one of ten electronic gift cards for [the equivalent of] 100 U.S. dollars each. If interested, please take the survey at your earliest convenience at the following address:http://tinyurl.com/osm-aug14. It will be available to the first 500 respondents during the month of August and the gift card winners will be notified in early September. Please contact Prof. Claudiu Dimofte, PhD (cdimo...@mail.sdsu.edu) if you have any questions. Thank you in advance for your potential participation and apologies for the lengthy message in case you are not interested. ___ Talk-in mailing list Talk-in@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-in
[Talk-it] Cartello limite di parco o riserva
In un bosco ho trovato il cartello della foto [1] ai margini di una torbiera. C'e' un modo codificato di indicarlo? Stessa domanda anche per i cartelli che, ad esempio, delimitano parchi o altre riserve. grazie maxx [1] http://www.emmexx.it/varie/osm/torbiera.jpg ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] online survey (academic research) about the OSM community
***apologies for cross-posting*** Dear OSM contributor, If you are at least 18 years of age and speak English, you are invited to take part in an online survey about the OSM community pursued by faculty at San Diego State University (contact info below). In this academic research, we are trying to understand what makes a highly diverse and dispersed group of individuals come together in the process of co-creation and what types of individuals tend to contribute to OSM. A similar project was pursued several years ago by Nama Budhathoki, PhD (seehttp://wiki.openstreetmap.org/wiki/Research), who is also involved in this research as we try to determine if and how contributor motivations may change over time as the community grows in numbers and expertise. You will be offered the opportunity to receive the overall results of the research project at its conclusion. The entire survey should take about 20 minutes and is completely anonymous. At the end of the survey, you have the option to provide an email address to be entered in a lottery for one of ten electronic gift cards for [the equivalent of] 100 U.S. dollars each. If interested, please take the survey at your earliest convenience at the following address:http://tinyurl.com/osm-aug14. It will be available to the first 500 respondents during the month of August and the gift card winners will be notified in early September. Please contact Prof. Claudiu Dimofte, PhD (cdimo...@mail.sdsu.edu) if you have any questions. Thank you in advance for your potential participation and apologies for the lengthy message in case you are not interested. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-co] Cómo producir un mapa *.img pequeño
Hola Efectivamente es com mkgmap que se genera, es solo descargar el área de osm que quieres generar y correr el script, es realmente muy fácil. On Friday, August 22, 2014, Federico Explorador federico.explora...@nevados.org wrote: Hola maper@s: Quiero producir un mapa (extracto) .img que me quepa en unos GPS Garmin etrex sencillos (Memoria interna 8 MB). Solo necesito el área entre Bogotá y Machetá, para apoyar la búsqueda de un guía desaparecido en el páramo de Guatanfur por la famila y un grupo de amigos ( http://www.eltiempo.com/colombia/otras-ciudades/busqueda-de-guia-jose-nevardo-guerrero-en-guatavita-/13953758 ). El mapa de Colombia que uso (http://openmtbmap.org/download/) está compuesto de varias áreas y antes he usado Mapsource pero transferir al GPS lo que necesito. Pero en esta ocasión el archivo del área - más grande – mide 15 MB y no me sirve. Recuerdo vagamente la herramienta mkmap, pero tendría que volver a aprenderlo. Alguien tiene una idea o me puede ayudar con eso? Saludos Federico -- ## |___|__\___ | _ | |_ | } (_) (_) Twitter: @fredy_rivera Phone USA: (347) 688-4473 Mobil telephone: +57 3044886255 ___ Talk-co mailing list Talk-co@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-co
Re: [Talk-co] Solicitud informacion RASTER
En el USGS (http://glovis.usgs.gov) puedes encontrar imágenes Landsat con resolución de 30 metros. Si combinas las imágenes con la banda pancromática incluso pueden llegar a 15 metros. En esta página también encuentras imágenes Landsat (glcfapp.glcf.umd.edu:8080/esdi/index.jsp) pero no sé si estén también las de Landsat 8. Saludos Nicolás Vargas El 22/08/2014, a las 2:27 p.m., Fulton Mercado f_merc...@yahoo.com escribió: creo que google earth tiene toda la cobertura por encima de eso Fulton Mercado Minka Construcciones El Viernes, 22 de agosto, 2014 2:21 P.M., hyan...@gmail.com hyan...@gmail.com escribió: Talvez en el http://earthexplorer.usgs.gov El ago 22, 2014 2:07 PM, carlos felipe castillo kaxti...@gmail.com escribió: Buena tarde. Alguna ayuda de un lugar donde pueda encontrar imágenes RASTER de Colombia con resolución de 90 mts o menor. Gracias. ___ Talk-co mailing list Talk-co@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-co ___ Talk-co mailing list Talk-co@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-co ___ Talk-co mailing list Talk-co@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-co
Re: [Talk-at] Straßenbahnen werden nicht gerendert
Simon Legner wrote: Der Effekt ist, dass die Straßenbahnen in Wien, Graz, Innsbruck sehr lückenhaft dargestellt werden. Linz ist wohl nicht betroffen, weil railway=tram nie (?) zusammen mit highway vorkommt. Wien wurde eh noch relativ verschont, weil alle zweigleisigen und einige eingleisige Abschnitte getrennt gemappte Gleise haben. Nur einige Schleifen und der Bereich Teichgasse sehen verwüstet aus (sowie einige vereinzelte separate Gleiskörper, die von den Nachtbussen befahren werden und deshalb als highway=service getaggt wurden). Viel schlimmer ist es z.B. in Prag (Praha, CZ) oder Padua (Padova, IT), dort sind fast alle Gleise verschwunden. Der Fehler sollte hoffentlich bald behoben sein, es gibt ja inzwischen einen Pull-Request (an dem ich auch beteiligt war). Es sollte auf jeden Fall nicht notwendig sein, alles nur wegen diesem Bug umzumappen. Wo allerdings schon umzumappen (zumindest umzutaggen) ist, wenn Gleise auf Brücken auf einmal aus dem Rendering verschwunden sind, weil der layer=-Tag nicht gesetzt war. Siehe auch: https://github.com/gravitystorm/openstreetmap-carto/issues/167 Wenn die Brücke layer=1 hat, dann müssen die Gleise das auch haben, und sinngemäß entsprechend für layer=2 usw. (Bisher waren die Straßenbahngleise immer obenauf, das wurde jetzt aber korrigiert.) Für Wien habe ich das bereits erledigt. (Da bin ich über alle Straßenbahnlinien drübergegangen, habe jedesmal die Brücken überprüft und gegebenenfalls layer=* (meistens layer=1) gesetzt.) Kevin Kofler ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-cz] Tracer - pLPIS - Nová verze
No vida, zdá se, že se mi podařilo vychytat většinu problémů s automatickou opravou překrývajících se ploch. Občas se můžou vyskytnout drobné problémky, třeba ocásky (ty zkusím nějak vyřešit) a taky to zatím nechává na pokoji relace. Tam se to musí upravit ručně. Taky to nedopadne dobře, pokud cesta prochází skrz celé pole tam a zpátky. Viz obrázky. Tam by to chtělo rozdělit na více ploch. Ale mám trochu problém s tím, jak tento konkrétní případ poznat. Nová verze: http://www.kyralovi.cz/tmp/josm/beta/20140823/Tracer.jar Zdrojáky (jako vždy): https://github.com/mkyral/josm-tracer/commits/plpis Marián Dne 20.8.2014 19:58, Marián Kyral napsal(a): Ahoj, tady máte novou verzi, která řeší problém se znakovou sadou na windows (nevyplněné landuse). Byla to docela fuška. Musel jsem svého tučňáka degradovat na úroveň windows - vypnout unicode v konzoli :-D A jak už to tak bývá, oprava byla nakonec úplně primitivní. Jen kdybych to byl býval věděl už na začátku :-D V této verzi by se už měly spojit společné body s vedlejším polygonem. (Občas se nějaká muška najde) Taky testuji novou verzi pro řešení překrývajících se ploch. V naprosté většině případů to funguje dobře, ale občas se to tak dotentuje, že nestačím zírat (a už vůbec ne chápat). Ale pomalu získávám praxi v řešení těchto šíleností. Hlavní problém je, že pole mají různé roztodivné tvary a bývají velká, lesy mají taky roztodivné tvary a bývají ještě větší no a to generuje zcela nečekané problémy. Zatím jsem tedy opravy překrývajících se ploch vypnul. http://www.kyralovi.cz/tmp/josm/beta/20140820/Tracer.jar Marián ___ 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] Tracer - pLPIS - Nová verze
Ještě ty obrázky ;-) Marián Dne 23.8.2014 10:06, Marián Kyral napsal(a): No vida, zdá se, že se mi podařilo vychytat většinu problémů s automatickou opravou překrývajících se ploch. Občas se můžou vyskytnout drobné problémky, třeba ocásky (ty zkusím nějak vyřešit) a taky to zatím nechává na pokoji relace. Tam se to musí upravit ručně. Taky to nedopadne dobře, pokud cesta prochází skrz celé pole tam a zpátky. Viz obrázky. Tam by to chtělo rozdělit na více ploch. Ale mám trochu problém s tím, jak tento konkrétní případ poznat. Nová verze: http://www.kyralovi.cz/tmp/josm/beta/20140823/Tracer.jar Zdrojáky (jako vždy): https://github.com/mkyral/josm-tracer/commits/plpis Marián Dne 20.8.2014 19:58, Marián Kyral napsal(a): Ahoj, tady máte novou verzi, která řeší problém se znakovou sadou na windows (nevyplněné landuse). Byla to docela fuška. Musel jsem svého tučňáka degradovat na úroveň windows - vypnout unicode v konzoli :-D A jak už to tak bývá, oprava byla nakonec úplně primitivní. Jen kdybych to byl býval věděl už na začátku :-D V této verzi by se už měly spojit společné body s vedlejším polygonem. (Občas se nějaká muška najde) Taky testuji novou verzi pro řešení překrývajících se ploch. V naprosté většině případů to funguje dobře, ale občas se to tak dotentuje, že nestačím zírat (a už vůbec ne chápat). Ale pomalu získávám praxi v řešení těchto šíleností. Hlavní problém je, že pole mají různé roztodivné tvary a bývají velká, lesy mají taky roztodivné tvary a bývají ještě větší no a to generuje zcela nečekané problémy. Zatím jsem tedy opravy překrývajících se ploch vypnul. http://www.kyralovi.cz/tmp/josm/beta/20140820/Tracer.jar Marián ___ 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] Tracer - pLPIS - Nová verze
díky za úpravu - vyzkoušej jsem jej a mám jeden poznatek: - tracer odstraňuje stará překrývající pole pouze ve vnitřku polygonu LPIS, pokud je staré pole větší než polygon LPIS tak zůstane zbytek původního pole Pražák Dne 23. srpna 2014 10:06 Marián Kyral mky...@email.cz napsal(a): No vida, zdá se, že se mi podařilo vychytat většinu problémů s automatickou opravou překrývajících se ploch. Občas se můžou vyskytnout drobné problémky, třeba ocásky (ty zkusím nějak vyřešit) a taky to zatím nechává na pokoji relace. Tam se to musí upravit ručně. Taky to nedopadne dobře, pokud cesta prochází skrz celé pole tam a zpátky. Viz obrázky. Tam by to chtělo rozdělit na více ploch. Ale mám trochu problém s tím, jak tento konkrétní případ poznat. Nová verze: http://www.kyralovi.cz/tmp/josm/beta/20140823/Tracer.jar Zdrojáky (jako vždy): https://github.com/mkyral/josm-tracer/commits/plpis Marián Dne 20.8.2014 19:58, Marián Kyral napsal(a): Ahoj, tady máte novou verzi, která řeší problém se znakovou sadou na windows (nevyplněné landuse). Byla to docela fuška. Musel jsem svého tučňáka degradovat na úroveň windows - vypnout unicode v konzoli :-D A jak už to tak bývá, oprava byla nakonec úplně primitivní. Jen kdybych to byl býval věděl už na začátku :-D V této verzi by se už měly spojit společné body s vedlejším polygonem. (Občas se nějaká muška najde) Taky testuji novou verzi pro řešení překrývajících se ploch. V naprosté většině případů to funguje dobře, ale občas se to tak dotentuje, že nestačím zírat (a už vůbec ne chápat). Ale pomalu získávám praxi v řešení těchto šíleností. Hlavní problém je, že pole mají různé roztodivné tvary a bývají velká, lesy mají taky roztodivné tvary a bývají ještě větší no a to generuje zcela nečekané problémy. Zatím jsem tedy opravy překrývajících se ploch vypnul. http://www.kyralovi.cz/tmp/josm/beta/20140820/Tracer.jar Marián ___ 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] Tracer - pLPIS - Nová verze
Ahoj. Tak to je správně. To větší překrývající pole by měl správně nahradit. Ale to zatím nefunguje ;-) Doporučuji zatím používat funkci nahradit geometrii z utils2 pluginu (tak nějak, nepamatuji si to přesně a jsem teď pryč). Marián On 23. srpna 2014 14:37:24 CEST, Zdeněk Pražák zpra...@seznam.cz wrote: díky za úpravu - vyzkoušej jsem jej a mám jeden poznatek: - tracer odstraňuje stará překrývající pole pouze ve vnitřku polygonu LPIS, pokud je staré pole větší než polygon LPIS tak zůstane zbytek původního pole Pražák Dne 23. srpna 2014 10:06 Marián Kyral mky...@email.cz napsal(a): No vida, zdá se, že se mi podařilo vychytat většinu problémů s automatickou opravou překrývajících se ploch. Občas se můžou vyskytnout drobné problémky, třeba ocásky (ty zkusím nějak vyřešit) a taky to zatím nechává na pokoji relace. Tam se to musí upravit ručně. Taky to nedopadne dobře, pokud cesta prochází skrz celé pole tam a zpátky. Viz obrázky. Tam by to chtělo rozdělit na více ploch. Ale mám trochu problém s tím, jak tento konkrétní případ poznat. Nová verze: http://www.kyralovi.cz/tmp/josm/beta/20140823/Tracer.jar Zdrojáky (jako vždy): https://github.com/mkyral/josm-tracer/commits/plpis Marián Dne 20.8.2014 19:58, Marián Kyral napsal(a): Ahoj, tady máte novou verzi, která řeší problém se znakovou sadou na windows (nevyplněné landuse). Byla to docela fuška. Musel jsem svého tučňáka degradovat na úroveň windows - vypnout unicode v konzoli :-D A jak už to tak bývá, oprava byla nakonec úplně primitivní. Jen kdybych to byl býval věděl už na začátku :-D V této verzi by se už měly spojit společné body s vedlejším polygonem. (Občas se nějaká muška najde) Taky testuji novou verzi pro řešení překrývajících se ploch. V naprosté většině případů to funguje dobře, ale občas se to tak dotentuje, že nestačím zírat (a už vůbec ne chápat). Ale pomalu získávám praxi v řešení těchto šíleností. Hlavní problém je, že pole mají různé roztodivné tvary a bývají velká, lesy mají taky roztodivné tvary a bývají ještě větší no a to generuje zcela nečekané problémy. Zatím jsem tedy opravy překrývajících se ploch vypnul. http://www.kyralovi.cz/tmp/josm/beta/20140820/Tracer.jar Marián ___ 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 -- Odesláno z mého telefonu s Androidem pomocí pošty K-9 Mail. Omluvte prosím moji stručnost.___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Odstávka LPIS
Takže LPIS WFS a WMS je dole. Doufám, že ta nová verze nic nepokazí :-D Marián Dne 22.8.2014 17:23, Marián Kyral napsal(a): Ahoj, tak jsem teď zavítal na webové rozhraní LPIS a co tam nevidím: Plánovaná odstávka registru půdy (LPIS) 19.8.2014 *V termínu 21.8. od 20h do 26.8. do 18h budou prováděny úpravy v registru půdy (LPIS). V tomto termínu nebude dostupné webové rozhraní veřejného LPIS a LPISu pro farmáře. Nedostupné budou také WMS služby a veřejné webové služby LPIS. Částečné omezení bude také v aplikacích napojených na LPIS a to, Data ke stažení, EPH, IZR a dále Registru vinic (RV). Odstávka se týká přípravy spuštění nové evidence půdy (LPIS). * http://eagri.cz/public/web/mze/farmar/LPIS/novinky/odstavka-lpis-1.html Tracer zatím funguje, ale až přestane, tak mi nenadávejte. Vypadá to, že budu mít čas i na něco jiného ;-) Marián* * ___ 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
[OSM-ja] iDエディタの翻訳についてヘルプ (ハイキング用語)
いいだです。 OSMエディタ iDの翻訳がTransifexで行われているのですが、 ここのところ、ハイキング・オフロードバイク用語が追加されて、 ちょっと翻訳が難しいかんじになっています。 だいたい定訳があるんだろうなぁ、という分野なので、 もし訳語に心当たりのあるかたは、提案機能からでも示唆いただけると嬉しいです。 https://www.transifex.com/projects/p/id-editor/language/ja/ ちなみに、iDの翻訳を追うと、だいたいどんな機能が実装されるのかが 先にわかって楽しいです。 是非是非。 -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
[Talk-GB] Bus diversions
This seems to be new to me: how long should a route diversion be for before being considered for inclusion on OpenStreetMap? A clarification may solve odd questions about temporary closures, and be part of the standards scheme on the wiki. Thanks. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Bus routes and names
On 20/08/14 20:45, Antje Maroussi wrote: Whereas I use London Buses route 24 Northbound” to help editors each variant so they can put it to the right bus stop, max93600 has been changing them carelessly with the comment Modifications diverses”: in this editor’s recent edits, so that both directions of Bus 24 read Relation: Bus 24 : Grosvenor Road ↔ Royal Free Hospital (see 3523629 v25 and 3523630 v26). My take on this is that, assuming there is no name regularly used by the public (and which applies to the whole of the mapped route): - route names should contain just enough to distinguish them from other route relations in the same area; - as far as possible should reflect how a member of the public might refer to them; - sort relative to other route relations in such a way that it is easy to find the correct one within a long list; - ideally sort correctly relative to ones without a name. I think that giving both to and from destinations is going to be wrong, unless there is are route variants that have different combinations. I think there is a case for using the destination when using route masters, as the destination will appear on the front of the bus. However, many people will use buses for short hops and may think of them in terms of the direction indicated on the stop, which is normally given as a place name much closer than the final destination, or in terms of the local direction of travel. However, the local direction of travel may be opposite to the general trend, so may not be useful for the overall route. I like the idea of the general trend direction, as it is a simple rule, but I think final destination may be more appropriate in some cases. An extreme case is circular routes. The cases near me are split into different route numbers for clockwise and anti-clockwise, but both list the same final destination. If sharing a route number, I think those would need to be distinguished using clockwise and anti-clockwise. (Are there any figure of eight routes?) Going back to your version, I think including the network also amounts to putting metadata in an invented name. Generally, you will not get the same route number with different networks, in the same area, as that would confuse the public. The exception might be national versus local buses, but that doesn't need the full network name. Considering the non-route master case, particularly, putting just the route reference as the name can clash with other networks, like cycling networks. Either you have to give buses a privileged status, or you need to include the fact that it is a bus route. If one throws in the sorting consideration, it is best to have the route number first. That is also consistent with common usage of bus names: catch the [number] 21 bus. Common usage might also include towards , but may be an intermediate place, or a local direction of travel, so might not be useful for naming the whole route. I'd therefore prefer: 999 Bus directionbound 999 Bus towards destination or 999 Bus [anti-]clockwise as appeared most useful in the context, and always giving precedence to some established name for the route. Incidentally, looking at one of the examples you gave, they had placed an origin in the name, but not in the metadata, so I think they may have had a poor understanding of metadata. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Bus routes and names
On 23/08/14 14:12, David Woolley wrote: I think that giving both to and from destinations is going to be wrong, unless there is are route variants that have different combinations. However, except that the wiki example uses a clearly directed =, this is basically the format used in the examples cited for the route master wiki entry, so it could be argued that they are doing the correct thing here, even though I would prefer to have the number first. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Bus routes and names
Maybe I could try “London Buses 38 → Victoria”? I just wanted to reduce the time it takes to find and update relation in JOSM, given that the much-needed modernisation is a big thing. Amaroussi (still trying to figure out why Mail insists in replying directly to sender!) On 23 Aug 2014, at 14:35, David Woolley for...@david-woolley.me.uk wrote: On 23/08/14 14:12, David Woolley wrote: I think that giving both to and from destinations is going to be wrong, unless there is are route variants that have different combinations. However, except that the wiki example uses a clearly directed =, this is basically the format used in the examples cited for the route master wiki entry, so it could be argued that they are doing the correct thing here, even though I would prefer to have the number first. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Bus routes and names
On 23/08/14 14:50, Amaroussi-OSM wrote: Maybe I could try “London Buses 38 → Victoria”? I don't think you need the network. The number should be locally unique without that. People don't qualify bus numbers by London bus in real life. I just wanted to reduce the time it takes to find and update relationin JOSM, given that the much-needed modernisation is a big thing. It is precisely to aid finding them in JOSM that I prefer to have the number first. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Bus routes and names
Sorry for doing experiments on the mailing list, but what about: 38 Bus 38 Bus → Victoria If this goes well I will put it in the wiki and reference the mailing list. After that we need to talk about the future of coach routes. On 23 Aug 2014, at 14:57, David Woolley for...@david-woolley.me.uk wrote: On 23/08/14 14:50, Amaroussi-OSM wrote: Maybe I could try “London Buses 38 → Victoria”? I don't think you need the network. The number should be locally unique without that. People don't qualify bus numbers by London bus in real life. I just wanted to reduce the time it takes to find and update relationin JOSM, given that the much-needed modernisation is a big thing. It is precisely to aid finding them in JOSM that I prefer to have the number first. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
