Re: [OSM-talk] Highway=trunk : harmonization between countries ?
On Sat, Feb 24, 2018 at 6:00 PM, Lester Caine wrote: > I think the main problem is that there are well established guidelines for > various areas on mapping data at both country and region level but in may > cases even those rules do not harmonize. We need the several levels of > highway that are currently accurately mapping UK roads, but other areas of > the world do not need that degree of classifications ... so they just don't > use the ones that are not appropriate ... highway=trunk is currently defined like this in the wiki: "high performance or high importance roads that don't meet the requirement for motorway. In different countries, either performance or importance is used as the defining criterion" So, is it "either" performance "or" importance, or "only one" of those two? It's hard for a local community to agree on which factors count when the definition is vague. What is missing is establishing the >> fundamental purpose << of classification of motorised ways at the global level. Suppose that "performance" is the desirable meaning. That suggests that classification should be done based on physical qualities of the road (leading to fragments of alternating class). If instead "importance" is the desirable meaning, we still need to know what makes the road important: relative or absolute traffic volume? Economics? Planning? Administrative level? Access rights of non-motorised modes? Is it the road's "function" as in "functional classification" [1][2]? Is it the road's suitability for freight [3]? Suppose that "freight" should be an important aspect for the trunk level for any country. That means that trunks must be suitable for truck traffic. That would make the following at least trunk (some might be motorway): - most US highways and interstates (it would be the National Freight Network [4]) - most national AND state highways in Brazil, except those with load restrictions and those that are unpaved and in poor condition (including main routes between several state capitals) - state highways in India (though perhaps not all of them, due to conservation problems - like in Brazil) [1] https://comparativegeometrics.wordpress.com/2013/05/16/how-many-levels-in-a-road-hierarchy/ [2] https://wiki.openstreetmap.org/wiki/User:NE2/classification_FAQ#Why_can.27t_we_use_functional_classification.3F [3] https://en.wikipedia.org/wiki/Trunk_road [4] https://ops.fhwa.dot.gov/freight/infrastructure/nfn/index.htm -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Highway=trunk : harmonization between countries ?
On Sat, Feb 24, 2018 at 2:51 PM, Martin Koppenhoefer wrote: > can you please point to some examples? Are you sure about the other maps? > They often don’t show many different road classes on first sight (but they > have them and you can see it as you zoom in and out that there must be more > properties or classes than you can distinguish by color or width) Sure. Let's begin with Matej's example: route 7 on Sulec, Czechia. It's not continuous in OSM, but it is in Google Maps, Here.com and Waze: - https://www.openstreetmap.org/#map=14/50.3083/13.8837 - https://www.google.com.br/maps/@50.30831134,13.88367320,14z - https://wego.here.com/?map=50.30828,13.88449,14,normal In Germany, there are many small stretches of trunk in the area between Berlin, Hamburg and Hannover. On the route Hamburg - Uelzen - Braunschweig, it happens twice along route B4: - in Uelzen: https://www.openstreetmap.org/#map=13/52.9611/10.5890 - in Gifhorn: https://www.openstreetmap.org/#map=13/52.4694/10.5244 No such changes in Google Maps, Here.com or Waze. In Openstreetmap.de, this leads to the interesting effect of knowing where the road is divided. However, that does not translate well elsewhere - for example, in England, on route A40 between Oxford and Gloucester, which is not divided: https://www.openstreetmap.de/karte.html?zoom=18&lat=51.80304&lon=-1.63750&layers=B000TT In Italy, on route SS12 between Verona and Modena, it also happens twice: - in Isolda della Scala: https://www.openstreetmap.org/#map=13/45.2730/11.0218 - in Mirandola: https://www.openstreetmap.org/#map=13/44.8679/11.0485 As in the other example, no such changes in Google Maps, Here.com or Waze. -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Highway=trunk : harmonization between countries ?
t; I think it's cute, but does not match on-the-ground data in countries where >>>> road classification is well-defined. >>>> >>>> Look, I've spent a lot of time on this and I have better things to do. >>>> Fill in the info for your regions on the wiki and then we can see what we >>>> can do. Until then, bear in mind that "harmonising" European roads will >>>> likely get you banned. I don't want to sound like I'm threatening you, but >>>> I've probably spent all the time I'm willing to spend on arguing with some >>>> random person who wants to break our local road classification system >>>> "because it will look nicer". >>>> >>>> On 24 February 2018 at 07:59, djakk djakk wrote: >>>>> >>>>> Yes, but this rendering does not change when a road crosses a border ^^ >>>>> >>>>> djakk >>>>> >>>>> >>>>> Le sam. 24 févr. 2018 à 05:43, JB a écrit : >>>>>> >>>>>> There is something I don't get. >>>>>> Draw primary the same color as trunk and you have no more « >>>>>> discontinuity »? >>>>>> In France, some commercial map (the most sold, I think) use a >>>>>> different >>>>>> rendering for trunk and primary, because you drive faster on trunks. I >>>>>> like it, I think they like it, because they have been using this >>>>>> rendering for decades. >>>>>> JB. >>>>>> >>>>>> Le 24/02/2018 à 04:45, Fernando Trebien a écrit : >>>>>> > As an exercise (and I'm curious about your thoughts on this), I >>>>>> > found >>>>>> > the main routes between place=city within Czechia (didn't have time >>>>>> > to >>>>>> > include cities in adjacent countries, bear that in mind). >>>>>> > >>>>>> > Here's the result [1] using the old colour scheme (motorway=blue, >>>>>> > trunk=green, primary=red; with a little mistake: secondary=yellow). >>>>>> > Top image uses the current classifications, and bottom image is the >>>>>> > result if city-city routes are classified as trunks. Looks very >>>>>> > similar to most other maps. Just by looking at it, it's quite >>>>>> > obvious >>>>>> > which is the main route between each pair of cities. As expected, >>>>>> > the >>>>>> > method also found out the best ways through and around Praha when >>>>>> > going across it. This could also be slightly improved - for example, >>>>>> > with little extra time, it is easier to recommend going through >>>>>> > route >>>>>> > 6 and then Karlovarská than through route 5 and Bucharova. >>>>>> > >>>>>> > I've checked the three small secondary segments using Street View. >>>>>> > Their physical structure is quite good. If still considered >>>>>> > undersirable, there are alternative main ways that increase the >>>>>> > total >>>>>> > time of travel very slightly. Not all routers agreed on taking them >>>>>> > anyway. >>>>>> > >>>>>> > [1] https://i.imgur.com/qFGSveX.jpg >>>>>> > >>>>>> > ___ >>>>>> > 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 >>>>> >>>> >> >> On 24 February 2018 at 10:39, djakk djakk wrote: >>> >>> Matej, you don’t have to answer quickly, you can answer one time per week >>> if you prefer, the strong arguments will still weight well :) >>
Re: [OSM-talk] Highway=trunk : harmonization between countries ?
n, but >>> elevating random primary roads to trunk is a loss of data for us. Touching >>> anything else than reclassifying primary to trunk et vice versa will >>> certainly be considered as vandalism in Czechia. >>> >>> You are demonstrating that you can guess the road class from other data. >>> I think it's cute, but does not match on-the-ground data in countries where >>> road classification is well-defined. >>> >>> Look, I've spent a lot of time on this and I have better things to do. >>> Fill in the info for your regions on the wiki and then we can see what we >>> can do. Until then, bear in mind that "harmonising" European roads will >>> likely get you banned. I don't want to sound like I'm threatening you, but >>> I've probably spent all the time I'm willing to spend on arguing with some >>> random person who wants to break our local road classification system >>> "because it will look nicer". >>> >>> On 24 February 2018 at 07:59, djakk djakk wrote: >>>> >>>> Yes, but this rendering does not change when a road crosses a border ^^ >>>> >>>> djakk >>>> >>>> >>>> Le sam. 24 févr. 2018 à 05:43, JB a écrit : >>>>> >>>>> There is something I don't get. >>>>> Draw primary the same color as trunk and you have no more « >>>>> discontinuity »? >>>>> In France, some commercial map (the most sold, I think) use a different >>>>> rendering for trunk and primary, because you drive faster on trunks. I >>>>> like it, I think they like it, because they have been using this >>>>> rendering for decades. >>>>> JB. >>>>> >>>>> Le 24/02/2018 à 04:45, Fernando Trebien a écrit : >>>>> > As an exercise (and I'm curious about your thoughts on this), I found >>>>> > the main routes between place=city within Czechia (didn't have time >>>>> > to >>>>> > include cities in adjacent countries, bear that in mind). >>>>> > >>>>> > Here's the result [1] using the old colour scheme (motorway=blue, >>>>> > trunk=green, primary=red; with a little mistake: secondary=yellow). >>>>> > Top image uses the current classifications, and bottom image is the >>>>> > result if city-city routes are classified as trunks. Looks very >>>>> > similar to most other maps. Just by looking at it, it's quite obvious >>>>> > which is the main route between each pair of cities. As expected, the >>>>> > method also found out the best ways through and around Praha when >>>>> > going across it. This could also be slightly improved - for example, >>>>> > with little extra time, it is easier to recommend going through route >>>>> > 6 and then Karlovarská than through route 5 and Bucharova. >>>>> > >>>>> > I've checked the three small secondary segments using Street View. >>>>> > Their physical structure is quite good. If still considered >>>>> > undersirable, there are alternative main ways that increase the total >>>>> > time of travel very slightly. Not all routers agreed on taking them >>>>> > anyway. >>>>> > >>>>> > [1] https://i.imgur.com/qFGSveX.jpg >>>>> > >>>>> > ___ >>>>> > 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 >>>> >>> > > On 24 February 2018 at 10:39, djakk djakk wrote: >> >> Matej, you don’t have to answer quickly, you can answer one time per week >> if you prefer, the strong arguments will still weight well :) >> >> djakk >> >> >> Le sam. 24 févr. 2018 à 10:30, djakk djakk a écrit >> : >>> >>> T
Re: [OSM-talk] Highway=trunk : harmonization between countries ?
As an exercise (and I'm curious about your thoughts on this), I found the main routes between place=city within Czechia (didn't have time to include cities in adjacent countries, bear that in mind). Here's the result [1] using the old colour scheme (motorway=blue, trunk=green, primary=red; with a little mistake: secondary=yellow). Top image uses the current classifications, and bottom image is the result if city-city routes are classified as trunks. Looks very similar to most other maps. Just by looking at it, it's quite obvious which is the main route between each pair of cities. As expected, the method also found out the best ways through and around Praha when going across it. This could also be slightly improved - for example, with little extra time, it is easier to recommend going through route 6 and then Karlovarská than through route 5 and Bucharova. I've checked the three small secondary segments using Street View. Their physical structure is quite good. If still considered undersirable, there are alternative main ways that increase the total time of travel very slightly. Not all routers agreed on taking them anyway. [1] https://i.imgur.com/qFGSveX.jpg ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Highway=trunk : harmonization between countries ?
On Fri, Feb 23, 2018 at 7:30 PM, Matej Lieskovský wrote: > Ok, look here: https://www.openstreetmap.org/#map=16/50.3124/13.8720 > The highway=trunk section is a bypass built to motorway specification. It is > not even a motorroad, because it is so short, but the change in the > character of the road is immense - it goes from 2 lanes to 2+2 lanes with a > median, gets wider borders, no pedestrians, cyclists or agricultural > vehicles allowed... The fact that it is drawn as a trunk road hints at all > these changes. You could also map it with lanes=4+foot=no+bicycle=no+agricultural=no and let the renderer decide whether these things are worthy of special representation or not. As a map user, I'm left with a bad impression of a map with such discontinuities, it looks messy and unprofessional. None of the commercial alternatives to OSM have such artifacts. You may also look for other maps of Czechia on Google Images and most won't show artifacts like that either. Also look at the classification of England, Australia and Russia in OSM and you won't find any similar artifacts. I doubt their roads never change structure over long distances. > On 23 February 2018 at 23:18, Fernando Trebien > wrote: >> >> Wouldn't the estimate change often? We usually don't like that in OSM. [1] >> >> [1] >> https://wiki.openstreetmap.org/wiki/Good_practice#Don.27t_map_temporary_events_and_temporary_features >> >> On Fri, Feb 23, 2018 at 7:11 PM, Matej Lieskovský >> wrote: >> > A "traffic" tag sounds like a good idea, but I'd have two suggestions: >> > 1) Can we find a better name? >> > 2) Estimates are better than words. I can imagine what 5000 cars per day >> > look like, but what is considered heavy traffic in (for example) Brazil? >> > >> > I'm all for letting highway tag only worry about high-level stuff >> > (footway, >> > cycleway, road, path...) and have a separate class tag for official >> > classification where needed. >> > >> > I've created this page: >> > https://wiki.openstreetmap.org/wiki/Highway_classes >> > Feel free to add your region! >> > >> > PS: +1 to Michael's point about not changing classifications in >> > countries >> > with an official system. >> > >> > On 23 February 2018 at 23:06, Michael Andersen wrote: >> >> >> >> On fredag den 23. februar 2018 15.31.37 CET Fernando Trebien wrote: >> >> >> >> > Assuming the map is correctly classified in Europe, I'm seeing many >> >> > fragments of motorways and trunks all over the map. Is this an >> >> > artifact of local definitions? Or is it intentional and desirable? >> >> >> >> The "fragments" of trunks you see in Denmark are intentional and >> >> desirable. We >> >> follow the official classifications. We will not be happy to see you >> >> change them. >> >> >> >> >> >> >> >> >> >> ___ >> >> talk mailing list >> >> talk@openstreetmap.org >> >> https://lists.openstreetmap.org/listinfo/talk >> > >> > >> > >> > ___ >> > talk mailing list >> > talk@openstreetmap.org >> > https://lists.openstreetmap.org/listinfo/talk >> > >> >> >> >> -- >> Fernando Trebien >> +55 (51) 9962-5409 >> >> "Nullius in verba." > > -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Highway=trunk : harmonization between countries ?
Wouldn't the estimate change often? We usually don't like that in OSM. [1] [1] https://wiki.openstreetmap.org/wiki/Good_practice#Don.27t_map_temporary_events_and_temporary_features On Fri, Feb 23, 2018 at 7:11 PM, Matej Lieskovský wrote: > A "traffic" tag sounds like a good idea, but I'd have two suggestions: > 1) Can we find a better name? > 2) Estimates are better than words. I can imagine what 5000 cars per day > look like, but what is considered heavy traffic in (for example) Brazil? > > I'm all for letting highway tag only worry about high-level stuff (footway, > cycleway, road, path...) and have a separate class tag for official > classification where needed. > > I've created this page: https://wiki.openstreetmap.org/wiki/Highway_classes > Feel free to add your region! > > PS: +1 to Michael's point about not changing classifications in countries > with an official system. > > On 23 February 2018 at 23:06, Michael Andersen wrote: >> >> On fredag den 23. februar 2018 15.31.37 CET Fernando Trebien wrote: >> >> > Assuming the map is correctly classified in Europe, I'm seeing many >> > fragments of motorways and trunks all over the map. Is this an >> > artifact of local definitions? Or is it intentional and desirable? >> >> The "fragments" of trunks you see in Denmark are intentional and >> desirable. We >> follow the official classifications. We will not be happy to see you >> change them. >> >> >> >> >> ___ >> talk mailing list >> talk@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk > > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Highway=trunk : harmonization between countries ?
I don't intend to. But I still wonder why they are desirable. On Fri, Feb 23, 2018 at 7:06 PM, Michael Andersen wrote: > On fredag den 23. februar 2018 15.31.37 CET Fernando Trebien wrote: > >> Assuming the map is correctly classified in Europe, I'm seeing many >> fragments of motorways and trunks all over the map. Is this an >> artifact of local definitions? Or is it intentional and desirable? > > The "fragments" of trunks you see in Denmark are intentional and desirable. We > follow the official classifications. We will not be happy to see you change > them. > > > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Highway=trunk : harmonization between countries ?
On Fri, Feb 23, 2018 at 5:25 PM, Mark Wagner wrote: > Which one is the "best"? If it's the fast route, there's no issue: > both roads are already "highway=motorway". I think the fastest route is almost always what most people would consider the best. The exception (probably rare/non-existent in the US) would be when the fastest route has infrastructure problems - say, it is a dirt road - while there are nearby routes with fewer problems (say a paved road that takes a little extra time because it is significantly longer). That being an exception, the local community can the discuss the exception (in the forum, so that it can be linked to from the map) and vote against making it the main route. > Fargo and Rapid > City are both larger than any city within 200 miles, which would > seem to make them "large/important", but even by western American > standards, they're pretty small in an absolute sense. I propose that place=* implies importance. Fargo has 105k inhabitants (place=city), Rapid City has 67k inhabitants (place=town). One highway class would connect cities (city-city), a lower class would connect towns and above (town-town, town-city), so the class of the ways making up the route between those places would be of the second class. If cities are connected by trunk and towns by primary, then the route between them would be primary. Now, which is the best route? Google insists on going through McIntosh, whereas Here.com and Waze prefer going through Sioux Falls or Dickinson depending on which direction you're going (mostly because the roads in the area are nearly a grid, which is a characteristic of the US that is not typical of most countries - that's worthy of some discussion). Nonetheless, there are few options to choose from. Google is the dissonant view, so maybe it should be initially ignored. The route through Sioux Falls is part of other routes between pairs of towns (say Sioux City - Grand Forks), so it must be a town-town route for at least that other reason. The remaining question then is whether the route Dickinson - Rapid City should be a town-town route. Dickinson has 17k inhabitants, so it is a town, so that route should be a town-town route. Which one is the main route between Fargo and Rapid City is then not relevant because both options are town-town routes for other reasons. If the situation did not allow us to ignore the problem, the next step would be to collect data (tracklogs), or publicly agree that both routes should be considered important because they're too similar (one possible improvement for the method). It should be noted that the route between Sioux Falls and Fargo would end up being classified as a city-city route because it is part of the main route between Kansas City (place=city, 459k people) and Winnipeg (place=city, 705k people). What if going through McIntosh is really the main route, or if all three routers are wrong? In that case, the initial analysis would be incorrect and the community would need to discuss that particular case and document it. It is possible that routers in the OSM ecosystem (OSRM, GraphHopper) can be used as long as relevant properties (maxspeed=*, and in places with deficitary infrastructure, surface=*) of route alternatives are mapped in OSM so that the routers can take them into account. What if, instead of the US, one is mapping in the UK, where place=* is defined according to public ordinances. In that case, the method still works, it just will judge a place's importance using another criterion instead of population. > Trunk, primary, > or secondary? > > -- > Mark > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Highway=trunk : harmonization between countries ?
I'm glad it is not so much of a problem in Czechia and I hope it would rarely be a problem anywhere. In any case, the idea can be developed further. Matej raises some interesting points that can account for better classification. For example, we could add some bias towards regional and/or national routes, in order to avoid shortcuts (though not forbid them completely if they are significant); likewise, we could add some bias to infrastructure, such as pavement quality, signage quality, feasibility for large vehicles (such as trucks), etc. Most interesting I think is to share with the global community how the local community understands classification. Are access rights really important to the map user, or is it only important to mappers? If so, why can't the renderer parse access tags to decide how to represent the way? (I believe that was the intention when motorroad=* was proposed.) On Fri, Feb 23, 2018 at 3:29 PM, djakk djakk wrote: > Don’t worry, when the official system is good, lik in Czechia, it matches > Fernando’s suggestion :) > > djakk > > > Le ven. 23 févr. 2018 à 18:32, Matej Lieskovský > a écrit : >> >> Don't get me wrong, this system might work well for countries without an >> official system, but what do you expect to happen in the EU? >> Will we have "highway=primary" + "class=tertiary" because some random road >> happens to be a shortcut? Or do you expect us in Czechia to use "class=II" >> while germans use "class=S" so that it actually matches the signage? Will >> the renderer parse ref numbers (and ignore the main tag) or will we receive >> hundreds of complaints about some section of the road having (what every >> local resident will consider to be) the wrong class? >> >> How do you determine "important cities" when even the line between towns >> and cities is country-dependant? Or is using administrative differences only >> not OK for roads? >> >> Even Waze actually follows local administration. >> >> >> Long story short: I am strongly against deploying this system in countries >> with a functioning official classification system. >> >> On 23 February 2018 at 18:06, Fernando Trebien >> wrote: >>> >>> +1 >>> >>> Administrative classification is not strictly related everywhere to >>> signage, structure and access rights. >>> >>> On Fri, Feb 23, 2018 at 1:12 PM, djakk djakk >>> wrote: >>> > I know that « trunk » is country-dependent but why not moving it to a >>> > worldwide definition ? Administrative classification could be moved to >>> > other >>> > tags :) >>> > >>> > >>> > djakk >>> > >>> > Le ven. 23 févr. 2018 à 16:06, Matej Lieskovský >>> > >>> > a écrit : >>> >> >>> >> Greetings >>> >> I'd like to caution against using this system globally. In Czechia, >>> >> roads >>> >> are formally classified into classes, which influence signage, ref >>> >> numbers >>> >> and so on. Deploying this system here would make the tag >>> >> confusing/useless >>> >> and would likely face enormous backlash. I have no problems with using >>> >> this >>> >> system in countries without a clearly defined road classification, but >>> >> please don't touch the countries where there is no doubt about what >>> >> class >>> >> any given road is. >>> >> Happy mapping! >>> >> >>> >> On 22 February 2018 at 16:20, djakk djakk >>> >> wrote: >>> >>> >>> >>> Hello, >>> >>> >>> >>> I totally agree with you, the definition you provide, >>> >>> administrative-free, tends to the same osm map between countries. >>> >>> >>> >>> djakk >>> >>> >>> >>> Le jeu. 15 févr. 2018 à 19:18, Fernando Trebien >>> >>> a écrit : >>> >>>> >>> >>>> Landing on this discussion several months late. I've just heard of >>> >>>> it >>> >>>> by reading a wiki talk page [1]. >>> >>>> >>> >>>> Since 13 February 2009, the wiki [2] criticises highway >>> >>>> classification >>> >>>> as problematic/unverifiable. This has also been subject to a lot of >>> >>>> controversy (an
Re: [OSM-talk] Highway=trunk : harmonization between countries ?
On Fri, Feb 23, 2018 at 3:31 PM, Fernando Trebien wrote: > Assuming the map is correctly classified in Europe, I'm seeing many > fragments of motorways and trunks all over the map. Is this an > artifact of local definitions? Or is it intentional and desirable? I should note that I don't see such artifacts in England, Australia, South Africa, Russia, Japan, among others. > On Fri, Feb 23, 2018 at 2:32 PM, Matej Lieskovský > wrote: >> Don't get me wrong, this system might work well for countries without an >> official system, but what do you expect to happen in the EU? >> Will we have "highway=primary" + "class=tertiary" because some random road >> happens to be a shortcut? Or do you expect us in Czechia to use "class=II" >> while germans use "class=S" so that it actually matches the signage? Will >> the renderer parse ref numbers (and ignore the main tag) or will we receive >> hundreds of complaints about some section of the road having (what every >> local resident will consider to be) the wrong class? >> >> How do you determine "important cities" when even the line between towns and >> cities is country-dependant? Or is using administrative differences only not >> OK for roads? >> >> Even Waze actually follows local administration. >> >> >> Long story short: I am strongly against deploying this system in countries >> with a functioning official classification system. >> >> On 23 February 2018 at 18:06, Fernando Trebien >> wrote: >>> >>> +1 >>> >>> Administrative classification is not strictly related everywhere to >>> signage, structure and access rights. >>> >>> On Fri, Feb 23, 2018 at 1:12 PM, djakk djakk >>> wrote: >>> > I know that « trunk » is country-dependent but why not moving it to a >>> > worldwide definition ? Administrative classification could be moved to >>> > other >>> > tags :) >>> > >>> > >>> > djakk >>> > >>> > Le ven. 23 févr. 2018 à 16:06, Matej Lieskovský >>> > >>> > a écrit : >>> >> >>> >> Greetings >>> >> I'd like to caution against using this system globally. In Czechia, >>> >> roads >>> >> are formally classified into classes, which influence signage, ref >>> >> numbers >>> >> and so on. Deploying this system here would make the tag >>> >> confusing/useless >>> >> and would likely face enormous backlash. I have no problems with using >>> >> this >>> >> system in countries without a clearly defined road classification, but >>> >> please don't touch the countries where there is no doubt about what >>> >> class >>> >> any given road is. >>> >> Happy mapping! >>> >> >>> >> On 22 February 2018 at 16:20, djakk djakk >>> >> wrote: >>> >>> >>> >>> Hello, >>> >>> >>> >>> I totally agree with you, the definition you provide, >>> >>> administrative-free, tends to the same osm map between countries. >>> >>> >>> >>> djakk >>> >>> >>> >>> Le jeu. 15 févr. 2018 à 19:18, Fernando Trebien >>> >>> a écrit : >>> >>>> >>> >>>> Landing on this discussion several months late. I've just heard of it >>> >>>> by reading a wiki talk page [1]. >>> >>>> >>> >>>> Since 13 February 2009, the wiki [2] criticises highway >>> >>>> classification >>> >>>> as problematic/unverifiable. This has also been subject to a lot of >>> >>>> controversy (and edit wars) in my local community (Brazil), >>> >>>> especially >>> >>>> regarding the effect of (lack of) pavement. >>> >>>> >>> >>>> In trying to achieve greater consensus some years ago, I decided to >>> >>>> seek opinions elsewhere and finally I arrived at this scheme [3] >>> >>>> which >>> >>>> I think is very useful, if not perfect yet. It can be easily >>> >>>> summarised like this: >>> >>>> - trunk: best routes between large/important cities >>> >>>> - primary: best routes between cities and above >>> >>
Re: [OSM-talk] Highway=trunk : harmonization between countries ?
What do you think about changes of classification at country borders? Can this be somehow reconciled? Assuming the map is correctly classified in Europe, I'm seeing many fragments of motorways and trunks all over the map. Is this an artifact of local definitions? Or is it intentional and desirable? On Fri, Feb 23, 2018 at 2:32 PM, Matej Lieskovský wrote: > Don't get me wrong, this system might work well for countries without an > official system, but what do you expect to happen in the EU? > Will we have "highway=primary" + "class=tertiary" because some random road > happens to be a shortcut? Or do you expect us in Czechia to use "class=II" > while germans use "class=S" so that it actually matches the signage? Will > the renderer parse ref numbers (and ignore the main tag) or will we receive > hundreds of complaints about some section of the road having (what every > local resident will consider to be) the wrong class? > > How do you determine "important cities" when even the line between towns and > cities is country-dependant? Or is using administrative differences only not > OK for roads? > > Even Waze actually follows local administration. > > > Long story short: I am strongly against deploying this system in countries > with a functioning official classification system. > > On 23 February 2018 at 18:06, Fernando Trebien > wrote: >> >> +1 >> >> Administrative classification is not strictly related everywhere to >> signage, structure and access rights. >> >> On Fri, Feb 23, 2018 at 1:12 PM, djakk djakk >> wrote: >> > I know that « trunk » is country-dependent but why not moving it to a >> > worldwide definition ? Administrative classification could be moved to >> > other >> > tags :) >> > >> > >> > djakk >> > >> > Le ven. 23 févr. 2018 à 16:06, Matej Lieskovský >> > >> > a écrit : >> >> >> >> Greetings >> >> I'd like to caution against using this system globally. In Czechia, >> >> roads >> >> are formally classified into classes, which influence signage, ref >> >> numbers >> >> and so on. Deploying this system here would make the tag >> >> confusing/useless >> >> and would likely face enormous backlash. I have no problems with using >> >> this >> >> system in countries without a clearly defined road classification, but >> >> please don't touch the countries where there is no doubt about what >> >> class >> >> any given road is. >> >> Happy mapping! >> >> >> >> On 22 February 2018 at 16:20, djakk djakk >> >> wrote: >> >>> >> >>> Hello, >> >>> >> >>> I totally agree with you, the definition you provide, >> >>> administrative-free, tends to the same osm map between countries. >> >>> >> >>> djakk >> >>> >> >>> Le jeu. 15 févr. 2018 à 19:18, Fernando Trebien >> >>> a écrit : >> >>>> >> >>>> Landing on this discussion several months late. I've just heard of it >> >>>> by reading a wiki talk page [1]. >> >>>> >> >>>> Since 13 February 2009, the wiki [2] criticises highway >> >>>> classification >> >>>> as problematic/unverifiable. This has also been subject to a lot of >> >>>> controversy (and edit wars) in my local community (Brazil), >> >>>> especially >> >>>> regarding the effect of (lack of) pavement. >> >>>> >> >>>> In trying to achieve greater consensus some years ago, I decided to >> >>>> seek opinions elsewhere and finally I arrived at this scheme [3] >> >>>> which >> >>>> I think is very useful, if not perfect yet. It can be easily >> >>>> summarised like this: >> >>>> - trunk: best routes between large/important cities >> >>>> - primary: best routes between cities and above >> >>>> - secondary: best routes between towns/suburbs and above >> >>>> - tertiary: best routes between villages/neighbourhoods and above >> >>>> - unclassified: best routes between other place=* and above >> >>>> >> >>>> For example, the best route between two villages would be at least >> >>>> tertiary. So would be the best route between a village and a
Re: [OSM-talk] Highway=trunk : harmonization between countries ?
+1 Administrative classification is not strictly related everywhere to signage, structure and access rights. On Fri, Feb 23, 2018 at 1:12 PM, djakk djakk wrote: > I know that « trunk » is country-dependent but why not moving it to a > worldwide definition ? Administrative classification could be moved to other > tags :) > > > djakk > > Le ven. 23 févr. 2018 à 16:06, Matej Lieskovský > a écrit : >> >> Greetings >> I'd like to caution against using this system globally. In Czechia, roads >> are formally classified into classes, which influence signage, ref numbers >> and so on. Deploying this system here would make the tag confusing/useless >> and would likely face enormous backlash. I have no problems with using this >> system in countries without a clearly defined road classification, but >> please don't touch the countries where there is no doubt about what class >> any given road is. >> Happy mapping! >> >> On 22 February 2018 at 16:20, djakk djakk wrote: >>> >>> Hello, >>> >>> I totally agree with you, the definition you provide, >>> administrative-free, tends to the same osm map between countries. >>> >>> djakk >>> >>> Le jeu. 15 févr. 2018 à 19:18, Fernando Trebien >>> a écrit : >>>> >>>> Landing on this discussion several months late. I've just heard of it >>>> by reading a wiki talk page [1]. >>>> >>>> Since 13 February 2009, the wiki [2] criticises highway classification >>>> as problematic/unverifiable. This has also been subject to a lot of >>>> controversy (and edit wars) in my local community (Brazil), especially >>>> regarding the effect of (lack of) pavement. >>>> >>>> In trying to achieve greater consensus some years ago, I decided to >>>> seek opinions elsewhere and finally I arrived at this scheme [3] which >>>> I think is very useful, if not perfect yet. It can be easily >>>> summarised like this: >>>> - trunk: best routes between large/important cities >>>> - primary: best routes between cities and above >>>> - secondary: best routes between towns/suburbs and above >>>> - tertiary: best routes between villages/neighbourhoods and above >>>> - unclassified: best routes between other place=* and above >>>> >>>> For example, the best route between two villages would be at least >>>> tertiary. So would be the best route between a village and a town or a >>>> city. Parts of this route might have a higher class in case they are >>>> part of a route between more important places. >>>> >>>> It surely raises the problem of determining optimal routes. Maybe a >>>> sensible criterion would be average travel time without traffic >>>> congestion. A number of vehicles may be selected for this average - >>>> could be motorcycle+car+bus+truck, or simply car+truck. >>>> >>>> Early results in my area [4, in Portuguese] seem promising and have >>>> produced more consensus than any previous proposals. To me, this >>>> method seems to: >>>> - resist alternations in classification along the same road >>>> - work across borders (where classification discontinuities are >>>> expected because each country is using different classification >>>> criteria) >>>> - account for road network topology >>>> - work in countries with mostly precarious/unpaved roads or >>>> without/unknown official highway classes >>>> - work between settlements as well as within settlements >>>> >>>> Borderline cases are probably inescapable in any system that does not >>>> use solely criteria that are directly verifiable - from the ground, or >>>> from the law. Maybe, in certain developed countries, the system is so >>>> well organized that merely checking signs/laws is sufficient. That >>>> does not mean it is like that everywhere on the planet. >>>> >>>> OSM has so far received a lot of input from communities in developed >>>> countries (mostly Europe, North America and Australia) and hasn't >>>> given much attention to less developed/organized countries. What comes >>>> closest to this is what the HOT Team does, but the judgment of road >>>> classification one can do from satellite images in a foreign country >>>> is much more limited than the criteria that have been raised in this >>>&
Re: [OSM-talk] Highway=trunk : harmonization between countries ?
ns/Road_Types/India [10] https://wazeopedia.waze.com/wiki/Brazil/Como_categorizar_e_nomear_vias [11] https://wazeopedia.waze.com/wiki/Germany/Kartenlegende_(Deutschland) [12] https://wazeopedia.waze.com/wiki/France/Classification_France [13] https://wazeopedia.waze.com/wiki/Italy/Tipologia_delle_strade [14] https://wazeopedia.waze.com/wiki/Indonesia/Panduan_Tipe_Jalan [15] https://wiki.waze.com/wiki/%E9%81%93%E8%B7%AF%E7%B1%BB%E5%9E%8B [16] https://wiki.waze.com/wiki/%E3%80%8C%E9%81%93%E8%B7%AF%E7%A8%AE%E5%88%A5%E3%80%8D -- Fernando Trebien +55 (51) 99962-5409 "Nullius in verba." ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Unsealed footways/cycleways/paths and rendering
Do you think it is necessary, for the general user, to visually distinguish unsealed (unpaved/poor surface) footways/cycleways/paths from those that are sealed? This has been raised in an issue related to unsealed roads (with focus on motorized traffic) [1]. Unsealed roads will probably get a visual hint when they contain on of the following tags (please discuss them here or in the appropriate list [2], not in the issue tracker): tracktype=grade2/grade3/grade4/grade5 smoothness=bad/very_bad/horrible/very_horrible/impassable surface=ground/dirt/earth/sand/grass For typical pedestrians and cyclists, some of these conditions might be ok. Not so much for wheelchair users, seniors, or people who don't want to get dirty when it rains. :P [1] https://github.com/gravitystorm/openstreetmap-carto/issues/110#issuecomment-116883466 [2] https://lists.openstreetmap.org/pipermail/tagging/2013-December/016007.html -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mappers and apps should focus on relations at the very start
Perhaps I expressed myself poorly. Previous arguments surrounded exclusively on "should this be done" or "why it shoudln't be done". The "easy" word refers only to "how should user interaction flow be in order to avoid breaking relations", without resorting to non-trivial dependency analysis algorithms (which, definitely, are more complex than adding a message or disabling a button upon a simple check that is mostly already implemented). On Sun, Jun 28, 2015 at 4:07 PM, Tom MacWright wrote: >> I see that the problem in iD is really easy to solve (much easier than in >> Potlach). > > Please never say this. Estimating that someone else's task, in their domain > of experience, is simple, is almost always incorrect, and usually > overstepping. "This painting looks pretty easy to paint: can you finish it > in an afternoon." > > If something is easy to do, please try doing it yourself and seeing whether > it is. Otherwise, don't tell other people that things should be easy for > them to do, so they should do what you want. People have been saying for > quite a while that it would be pretty easy for us to improve the software > that manages and edit OpenStreetMap, but none of them have decided to do it > in an afternoon, much less own the responsibility of maintaining and > defending the changes. > > iD has, to date, consumed thousands of hours of developer time, > communications, documentation authoring, and design. The same goes for > Potlatch and JOSM and the website. Developing these projects is even more > time-consuming because every change needs to be discussed to death, everyone > must be consulted, and then after release, we have to catch up with all of > the people who want to be consulted but don't read the mailing list. > > In short, if you believe this is easy, do it. Otherwise, don't underestimate > other people's tasks. > > On Sun, Jun 28, 2015 at 2:34 PM, Fernando Trebien > wrote: >> >> On Sun, Jun 28, 2015 at 4:03 AM, Richard Fairhurst >> wrote: >> > What is unacceptable is the relentless, harrying, dismissive, abusive >> > manner >> > in which you and others advance the former view over the latter. That is >> > why >> > we cannot retain developers. >> >> We really need to be careful to target the philosophical standpoint, >> not the people. As I said (now countless times), iD is awesome. I >> don't think I've been criticizing developer talent or code quality. I >> wouldn't have provided most of its translations into my language if I >> thought differently. Anyway, should this conversation be about iD? In >> a way yes, but not only. Other editors (except JOSM) seem to have the >> same aversion of relations. Relations are valuable and are not going >> away, several of them (the most critical being "route") have been >> approved long ago by the community (by consensus, by public voting), >> so I believe fighting them only make things worse. Fighting them is >> fighting the community. Others, such as boundary, are de facto >> standards. They have to be properly tamed. One way is to hide them so >> that only "clever" people can deal with them. Another is to teach >> everybody in the simplest possible manner so that they become widely >> accessible. >> >> Cliché quote: "Make things as simple as possible, but not simpler," >> some attribute to Einstein. >> >> When people are deleting and combining ways, they are editing >> invisible data - tags and parent relations. In a world without >> relations, combining different tags would still be an issue. For >> instance, the "sidewalk" tag is not visible. It should be visible. If >> it ever becomes visible, there is still a huge repository of approved >> tags that won't be. The current approach - concatenation - is >> essentially invisible in many situations (the user must pay a lot of >> attention at the result). I would like to see a scenario where a >> casual mapper (the target audience of all editors besides JOSM) would >> prefer not to be notified about a potential mistake. I do mapping >> sprints very often, I'm knowledgeable, and even so I prefer to get >> interrupted in my mapping whenever I do something potentially >> damaging. Without that, even with my experience, I would have broken >> data multiple times. How is that casual mappers would prefer not to >> have that? It is a contradiction to design the application for casual >> mappers and still place fastest mapping at utmost priority. A casual >> mapper is not aware of the data
Re: [OSM-talk] Mappers and apps should focus on relations at the very start
On Sun, Jun 28, 2015 at 4:03 AM, Richard Fairhurst wrote: > What is unacceptable is the relentless, harrying, dismissive, abusive manner > in which you and others advance the former view over the latter. That is why > we cannot retain developers. We really need to be careful to target the philosophical standpoint, not the people. As I said (now countless times), iD is awesome. I don't think I've been criticizing developer talent or code quality. I wouldn't have provided most of its translations into my language if I thought differently. Anyway, should this conversation be about iD? In a way yes, but not only. Other editors (except JOSM) seem to have the same aversion of relations. Relations are valuable and are not going away, several of them (the most critical being "route") have been approved long ago by the community (by consensus, by public voting), so I believe fighting them only make things worse. Fighting them is fighting the community. Others, such as boundary, are de facto standards. They have to be properly tamed. One way is to hide them so that only "clever" people can deal with them. Another is to teach everybody in the simplest possible manner so that they become widely accessible. Cliché quote: "Make things as simple as possible, but not simpler," some attribute to Einstein. When people are deleting and combining ways, they are editing invisible data - tags and parent relations. In a world without relations, combining different tags would still be an issue. For instance, the "sidewalk" tag is not visible. It should be visible. If it ever becomes visible, there is still a huge repository of approved tags that won't be. The current approach - concatenation - is essentially invisible in many situations (the user must pay a lot of attention at the result). I would like to see a scenario where a casual mapper (the target audience of all editors besides JOSM) would prefer not to be notified about a potential mistake. I do mapping sprints very often, I'm knowledgeable, and even so I prefer to get interrupted in my mapping whenever I do something potentially damaging. Without that, even with my experience, I would have broken data multiple times. How is that casual mappers would prefer not to have that? It is a contradiction to design the application for casual mappers and still place fastest mapping at utmost priority. A casual mapper is not aware of the data model, and should not be expected to be so. Back to the problem that motivated me into this discussion: I see that the problem in iD is really easy to solve (much easier than in Potlach). If there is an objection to an interaction-blocking modal window, other non-blocking visual cues can be used, such as a distinctive alert bar at the bottom, an alert icon at the action button, and an alert log on top after an action breaks something. Anything that informs the user is fine. It is not done only due to a philosophical opinion, which I think is negative to OSM as a whole. The opinion is negative, not the people that hold it. Maybe people are also being idealistic: instead of implementing a little workaround, they'd rather wait and see if a cleverer, less intrusive solution emerges. It is clearly not happening, after two years of waiting and wondering by the most involved minds in the project. Getting a simple alert when deleting relation members was a huge struggle. Since "combining" implies "deleting" I don't think the current issue should need to be so widely discussed. The only reason I don't set out and try writing my own editor (which is a pretty big undertaking) is that my country's map still needs lots of data, and my country's community still needs lots of support. Potlatch, iD and JOSM have solved that, mostly. All I ask for is a minor refinement, which I believe is good not only here but in the whole world. -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mappers and apps should focus on relations at the very start
Interesting, I remember long ago trying to upload (by accident) a set of relations with a cyclic dependency and receiving a server error. Maybe the message was phrased in a misleading way but the error was actually generated by JOSM. Will try again. Dependency checking must be aware of cycles, otherwise it may end up running an infinite loop. There are some other scenarios, such as retrieving a relation's incomplete members, where a self-reference can be problematic, but that's not the server's responsibility. I can't imagine right now any scenario where self-references or cyclic references woud be necessary to represent any information. (Not suggesting the the server should implement that check.) On Sat, Jun 27, 2015 at 9:03 PM, Paul Norman wrote: > On 6/27/2015 1:14 PM, Fernando Trebien wrote: >> >> Actually no, the server checks for circular dependencies, and a >> relation pointing to itself is a cycle. Try it, the server returns a >> validation error. > > Nothing in the OSM data model prohibits a relation that references itself, > or relations that form a cycle. > > As an example, see https://www.openstreetmap.org/relation/1368401 which > contains itself twice. Longer cycles are also possible. > > I can't imagine a case where a cycle is sensible, and they are often > difficult to delete, first requiring modifying the relations to remove the > cycle, then deleting the relations. > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mappers and apps should focus on relations at the very start
k those kinds of relations, you won't know, because you can't see > the breakage on the map, only in some software that you probably aren't > using. Which map are you talking about? The one the editor displays, the one on the main website, or some other apps' view of map data? On JOSM you do see very clearly when a multipolygon/boundary is broken, they are rendered as "open areas" (which are filled but missing one side). You don't get to see broken routes (for now), but there's a validator to tell you that the route you messed up with (even if you didn't edit the relation directly) is missing a piece. Double click the validator warning and it will highlight where the problem is and the unconnected ways in the route relation. It is very precise and visually clear. This problem is similar to that of lines whose nodes overlap exactly but are not connected. JOSM solves this by rendering the node differently when it is connected. Other editors don't care. When two streets overlap exactly, no editor shows you that they overlap. Even basic things are sometimes not visible to the mapper, no matter the level of experience. > The problem coming from the "building an editor" perspective is that > relations add a level of complexity to the question of "not breaking data" > that wholly explains why it's such a rarely attempted feat to "edit all > openstreetmap data". I would love if this problem were fixable with > documentation, but unfortunately, this is actually just a deep issue that > isn't easy to document, and iD would still be grilled on the regular for not > preventing people from doing things. Again, this is not targeted at iD, but JOSM does a good job and I think good ideas should be at least considered. I also think that JOSM is way more complex, and if the good idea requires a lot of development complexity, then maybe similar, but not-as-good ideas should be considered too. > The data model could be improved in a few ways: if it embraced the > long-awaited area datatype[1] and stopped using relations as a brittle > stopgap around multipolygons and node limits. Or if it specified & enforced > well-established types of relations in such a way that the validity of an > editor's approach was agreed-on rather than constantly argued about. I kind of agree, but this brings us down to two other topics: - areas as relations: pretty much the same discussion as with ways; this could be related to multipolygons in some aspects - the server performing validation, which is probably controversial because it would impose complexity on apps Besides, OSM lets people invent tags freely. Why wouldn't it let people invent relations too? It's this freedom that has made some relations emerge and then be phased out as people realized they weren't good enough. To truly let people invent things, two basic problems need to be well solved: have a good tag editor, and have a good relation editor. If ways and tags were the same entity, that would translate to a single relation editor and the work would be greatly reduced. > And it's not that I hate relations: they are truly one of the only > successful instances of "linked data" in the entire world of computers. > They're also a legitimate reflection of the world's actual complexity. But > reconciling their ephemeral, non-visual, intensely-freeform properties with > the ideal of "a map of the world everyone can edit" is not a simple matter. I know that. I actively avoid relations whenever possible, but routes have no other better solution, and while boundaries could be expressed as simple areas (closed ways), that would cause two problems: - lots of space lost in the server by replicating point references - editing usability while handling areas that share edges (not uncommon) [1] http://taginfo.openstreetmap.org/keys/type#values [2] http://taginfo.openstreetmap.org/keys/route#values [3] http://wiki.openstreetmap.org/wiki/Types_of_relation [4] http://wiki.openstreetmap.org/wiki/Empty_relations > Tom > > [1]: http://blog.jochentopf.com/2012-11-26-an-area-datatype-for-osm.html > [2]: http://wiki.openstreetmap.org/wiki/Empty_relations > > On Sat, Jun 27, 2015 at 12:58 PM, Fernando Trebien > wrote: >> >> This is surely going to spur controversy, but here I go. >> >> Imagine a world in which a new mapper opens its (newly-discovered) >> favourite editor and is presented with the following message the first >> time they edit anything: >> >> "You can map using points and relations. Relations are groups of >> things with specific roles: groups of points make lines, groups of >> lines can make things like routes bus routes, city boundaries, hollow >> buildings, turn restrictions, etc., groups
[OSM-talk] Mappers and apps should focus on relations at the very start
This is surely going to spur controversy, but here I go. Imagine a world in which a new mapper opens its (newly-discovered) favourite editor and is presented with the following message the first time they edit anything: "You can map using points and relations. Relations are groups of things with specific roles: groups of points make lines, groups of lines can make things like routes bus routes, city boundaries, hollow buildings, turn restrictions, etc., groups of routes can make route networks. Mappers rarely group further, but they could. Because lines are very common, you can draw them by simply adding many points one after another. If you want to make more complex relations such as routes and boundaries, check out the relation editor." Of course, such an editor would have to be designed with that philosophy in mind from the start. Is this a rant? Not really, this a sincere impression I've had for a very long time. Many novice users are confused by relations because they need to build their understanding later, often when someone complains they've made some mistake. When this notion of "grouping" is presented at the very beginning, I believe people will easily understand it for all of the advanced scenarios (the most common being routes and boundaries). It would just be didactic. Some people have even proposed abolishing the "way" entity from OSM's API and replacing it with a relation "type=way" with "node" members. Some logic (such as checking for empty ways/empty relations and checking membership across different entities) would be simplified, which would be good for database maintenance. It would also be good for app development, apps would have to understand relations from the very start and would thus be encouraged to support advanced features. That would be very little extra development overhead compared to just points and lines. I understand that very big relations with lots of nodes and a single role for all of them would be undesirable. Apps like the editor can still make the "way" entity transparent to the user, so an API change is not really required for a change in editor/mapper mindset. Still, I raise this aspect because, in an abstract sense that mappers do need to develop, ways are simply a "type of relation", and they could be concretely so. Relations cannot be abolished (there is no other way to represent bus/car/hiking/boat routes, or hollow polygons). Ways, in theory, can. -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Flash message when loading the wiki
Sorry for the spam, apparently this problem is only affecting me. On Sat, Apr 26, 2014 at 1:39 PM, Fernando Trebien wrote: > Am I the only person getting a weird Adobe Flash Player message while > trying to access any page of the wiki? Tried two different computers > and one mobile phone, same result. > > The download link redirects to a ZIP file in some suspicious IP > address. Seems hacked. > > -- > Fernando Trebien > +55 (51) 9962-5409 > > "Nullius in verba." -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Flash message when loading the wiki
Am I the only person getting a weird Adobe Flash Player message while trying to access any page of the wiki? Tried two different computers and one mobile phone, same result. The download link redirects to a ZIP file in some suspicious IP address. Seems hacked. -- Fernando Trebien +55 (51) 9962-5409 "Nullius in verba." ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] City templates - Links OFF
Hi Erick,
All wiki templates have URLs in this format:
http://wiki.openstreetmap.org/wiki/Template:[template name]
So all you need is to figure out the template name. I know you've been
mapping in Brasília, so I guess the city page you want to edit is this
one: http://wiki.openstreetmap.org/wiki/Bras%C3%ADlia
If you go into raw view or edit mode, you'll notice right at the beginning:
{{pt-br:place|name=Brasília|type=city|area=Distrito Federal|image=|
lat = -15.780 | long = -47.930 | zoom = 12}}
pt-br:place is the template name you're after. The rest is a bunch of
template parameters.
The "pt-br" prefix means the template is only used by articles from
the Brazilian community, so you may wish to contact the local
community to see if these changes are ok.
On Fri, Mar 28, 2014 at 2:37 PM, Erick de Oliveira Leal
wrote:
> In the city template, links like below are off, how to edit this template to
> not show this links?
>
> http://tah.openstreetmap.org/MapOf/?lat=-15.7896&long=-47.8221&z=9&w=1280&h=1024&format=jpeg
> http://gazetteer.openstreetmap.org/namefinder/?find=parking+near+Distrito+Federal
> http://random.dev.openstreetmap.org/no-names/?zoom=9&lat=-15.7896&lon=-47.8221&layers=0B000
> http://www.fxfoo.com/osm/kml/web/web-osm-world-day-latest-v0-openlayers.html?lat=-15.7896&lon=-47.8221&zoom=9&layers=B0T
> http://tile.openstreetmap.nl/coastlines.html?lon=-47.8221&lat=-15.7896&zoom=9&layers=B00T
>
> And this, does not aggregate any information, why it should be there?
> http://tah.openstreetmap.org/MapOf/?lat=-15.7896&long=-47.8221&z=9&w=1280&h=1024&format=jpeg
> http://www.webshots.com/
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
--
Fernando Trebien
+55 (51) 9962-5409
"The speed of computer chips doubles every 18 months." (Moore's law)
"The speed of software halves every 18 months." (Gates' law)
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Talk-us] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
Possible reasons: - they don't want their clients to think they're being guided by maps that are not made by professionals (a silly prejudice) - they don't want to tell the world that OpenStreetMap exists by adding attribution to their software UI (possibly due to existing contracts or branding) But I think that's silly: - http://www.navigon.com/portal/uk/kundenservice/faq.html?id=20208453&content_identifier=faq&page=28 - http://www.garmin.com/uk/topolight/ - http://techcrunch.com/2014/01/30/telenav-buys-skobbler/ On Mon, Mar 17, 2014 at 7:05 PM, Johan C wrote: > So we're wondering why OpenStreetMap, being better (superior?) than Google > in map data, is not used by commercial companies like BMW. Is there a native > German on this list who can ask BMW why they're not using OSM? > > > 2014-03-17 21:55 GMT+01:00 Michael Kugelmann : > >> Am 17.03.2014 04:53, schrieb Hans Schmidt: >> >>> If I, as a company, would use some map provider, I would definitely go >>> for "at least everywhere a minimum level of coverage" instead of only a >>> few places with excellent coverage. >> >> There was a comparison about Google and OSM a fow years ago. It showed >> that even on some non-European countries (e.g. Africa) a lot of citties are >> mapped better in OSM than Google: at least at that time there was no >> financial benefit for the commercial map providers to map all these places. >> Maybe this improved a little bit, but I don't think so... >> >> >> Best regards, >> Michael. >> >> >> >> ___ >> talk mailing list >> talk@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk > > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > -- Fernando Trebien +55 (51) 9962-5409 "The speed of computer chips doubles every 18 months." (Moore's law) "The speed of software halves every 18 months." (Gates' law) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Maximum recommended length of ways tagged with layer
I think stereotyping by nationality is quite un-OSM too. (I'm Brazilian, btw.) I think validators have a significant role in the current problem: we need a warning about missing bridges/tunnels when two ways overlap, regardless of the value in the "layer" tag of either way. This will discourage the use of layer=-1 on rivers to avoid validation warnings, and will also reveal when this was done and encourage people to effectively map bridges and tunnels. I now agree that the "layer" tag should be used as locally as possible, so I think Richard had good intentions when proposing this. At the same time, I think you, Frederik, has a good point that arriving at a threshold for that number is quite hard. What exactly do we want to avoid? Really, really long ways with a layer tag. So why not set this threshold higher? Say 10 km? On Sat, Mar 15, 2014 at 1:12 PM, Frederik Ramm wrote: > Hi, > > On 15.03.2014 14:44, Richard Z. wrote: >> I think it would be good to agree on something... >> https://wiki.openstreetmap.org/wiki/Talk:Key:layer#Maximum_recommended_segment_length_of_ways_tagged_with_layer > > I think that choosing some fixed number would be un-OSM. Your idea that > length limits should apply to certain layers but not others strikes me > as odd. You have already written down a rule that people shouldn't use > layer=-1 to hide validator warnings; no need to breathe down mapper's > necks with ever more detailed rules. It's not a German project ;) > > 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 -- Fernando Trebien +55 (51) 9962-5409 "The speed of computer chips doubles every 18 months." (Moore's law) "The speed of software halves every 18 months." (Gates' law) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
Under which license would you share it? And why? OSM offers you so many opportunities, I wonder what could be missing. On Mar 13, 2014 11:28 AM, "Alex Barth" wrote: > Hello everyone - > > I've been sitting on writing about the detrimental effects of > OpenStreetMap's share-alike license (ODbL) for a while and finally decided > to, um, share. I've been listening long to many OpenStreetMappers I respect > a ton telling me it's not so bad and it's just what we're stuck with right > now. But given how bad share alike is for OpenStreetMap I don't think we > should give up for pushing for a more open license. Here's why I think > share-alike hurts OpenStreetMap and how this keeps OpenStreetMap from > having the full impact it could have: > > http://www.openstreetmap.org/user/lxbarth/diary/21221 > > Looking forward to your comments, > > Alex > > > ___ > 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] Potlatch deprecation
It is not that easy to damage relations in JOSM. Sure, you can, but you get blocking warnings: once, when you change the relation indirectly (perhaps breaking it), and another (issued by JOSM's very comprehensive validator) by the time you attempt to upload your changes. Both warnings stop your work (always! there's no way to turn them off), make you read, ask you to decide how to handle the situation, and are quite informative: they tell you where you acted and what was the result. It sure is a bit low level, but that is good teaching. If you do not understand what you read, you can then go search for help. But if you get no warning (as in Potlatch), you don't even know you need to seek learning about relations. It is very hard to argue that someone can "miss" both warnings "accidentally". Can the user damage the relations with JOSM? Sure. But the user has been warned twice and should know what he/she is doing. They may ignore the warnings if they do not know what they mean, but then you have a better point to later approach the user and tell him/her to be more careful and read more about relations. If you do that to Potlatch users, it is totally fair if they reply: "How could I have known?" You can't expect them to re-read all that is written everywhere on the UI at every change they perform on the map. Potlatch should call their attention to important things (such as unintentional data loss). Even experienced users may accidentally destroy relations in Potlatch because of a short moment of inattention. In JOSM, you're always reminded. On Fri, Feb 21, 2014 at 9:08 PM, Bryce Nesbitt wrote: > I think all three major editors make it too easy to damage relations. > > And that starting to damage a relation (by a user) is a perfect teaching > opportunity. > The moment someone deletes part of a boundary relation, > is the perfect teaching moment about boundary relations. > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > -- Fernando Trebien +55 (51) 9962-5409 "The speed of computer chips doubles every 18 months." (Moore's law) "The speed of software halves every 18 months." (Gates' law) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Potlatch deprecation
Indeed that's a nice feature I've known to be unique to Potlatch. Anyway, I might have been misinformed about Potlatch being deprecated (if it was, I was trying to ask people to hurry), but since it's not, I'm not asking for it either. Instead, the issues I've pointed out (http://forum.openstreetmap.org/viewtopic.php?id=24381) need attention. They've been happening since I started in OSM over one year ago, and it's been hard lately to keep up with the growing introduction of these errors as the Brazilian community has grown a lot. Knowing that countries like the UK, Germany and Russia have a lot more edits, I'm actually puzzled: how do they manage these problems there? I only revert someone else's changeset as a last resort (when the user has really misunderstood almost everything), and these mistakes I've talked about are often part of a larger edit (where the idea of reverting does is problematic, as there's useful information in it). I know many tools (JOSM's validator, Geofabrik, KeepRight!, etc.) are able to detect problems, but none helps you quickly recover the previous state of a single broken relation along with the previous version of its members while still being consistent with the new data (some of the new ways might need to be deleted, some of their tags may need to be imported to the old ways, etc.). So relations can be broken in seconds, then people who are concerned about data integrity (particularly about the integrity of what they've previously mapped) end up spending many minutes every time such a mistake happens. And for that reason, I've been recommending against using streets as boundaries for suburbs - instead, drawing an independent way for that (which is inaccurate and should not be necessary). I've also been recommending people to use multipolygons only when extremely necessary. I shouldn't be recommending neither of the two, but I see no other way to prevent what I've pointed out. On Fri, Feb 21, 2014 at 6:10 AM, Pieren wrote: > On Thu, Feb 20, 2014 at 9:51 PM, Fernando Trebien > wrote: > > When I cannot use JOSM for any reason, I'm still using P2 to retrieve > the history of an object and P1 is the only one I know which is able > to find and display deleted ways. Two helpful features for data > maintenance. > > Pieren > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk -- Fernando Trebien +55 (51) 9962-5409 "The speed of computer chips doubles every 18 months." (Moore's law) "The speed of software halves every 18 months." (Gates' law) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Potlatch deprecation
I understand. Well, at least with iD there's a trend towards fixing these problems, since it is actively developed, whereas in Potlatch I'm sure none of the issues will ever be addressed. I've decided to expand on the main issues and ended up writing this: http://forum.openstreetmap.org/viewtopic.php?id=24381 I'm sure that this little thing would solve most of the major problems with relations in iD: https://github.com/openstreetmap/iD/issues/1461 On Fri, Feb 14, 2014 at 5:49 PM, malenki wrote: > On 14.02.2014 16:54, Fernando Trebien wrote: > >> My main issue is lack of proper support to relations (not displayed >> and handled improperly on basic operations, such as when merging and >> spliting way members, and not going to be fixed AFAIK). > > It doesn't help you question but iD has similar problems. It neither > renders membership to relations (but you see it when scrolling down > the left menu to the bottom) nor warn when a member of a relation gets > deleted. > Issues filed against iD regarding relations you can find here: > https://github.com/openstreetmap/iD/search?q=relation&ref=cmdform&type=Issues > > Thomas > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk -- Fernando Trebien +55 (51) 9962-5409 "The speed of computer chips doubles every 18 months." (Moore's law) "The speed of software halves every 18 months." (Gates' law) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Potlatch deprecation
Hello everyone, I was wondering when is it that Potlatch will be considered officially deprecated (so, taken out of the main website). I know that the editor has its pros (Flash is sometimes faster than iD's JavaScript, and some users certainly prefer Potlatch's menu organization), and I definitely appreciate the role it has played in OSM previously, but some of its cons make map maintenance an unnecessary pain. My main issue is lack of proper support to relations (not displayed and handled improperly on basic operations, such as when merging and spliting way members, and not going to be fixed AFAIK). Six months ago when I first posted the problem below, I was seeing problematic changesets in my city every now and then, but now, as the Brazilian community has grown quite a lot, I'm hearing of similar problems popping up in many other cities. Let me show you the case of these 4 turn restriction relations: http://www.openstreetmap.org/changeset/20391254 They have been deleted by this changeset: http://www.openstreetmap.org/relation/3490365 The user didn't know he was destroying data because Potlatch neither displays turn restrictions nor issues a warning when merging ways referenced by relations. It's been like this since I've joined OSM over 15 months ago, and I've seen this happening and had to fix them all manually many times. -- Forwarded message -- From: OpenStreetMap Date: Thu, Jul 18, 2013 at 3:31 AM Subject: Re: [OpenStreetMap] #4902: Warnings for deleting/merging relation members To: fernando.treb...@gmail.com, potlatch-...@openstreetmap.org #4902: Warnings for deleting/merging relation members -+ Reporter: fernando.trebien@... | Owner: potlatch-dev@... Type: enhancement | Status: new Priority: minor | Milestone: Component: potlatch2 |Version: Resolution: | Keywords: -+ Comment (by Richard): Potlatch will not be the default editor for much longer (iD will be) so purely beginner-focused feature requests are largely out of scope now. -- Ticket URL: <https://trac.openstreetmap.org/ticket/4902#comment:1> OpenStreetMap <http://www.openstreetmap.org/> OpenStreetMap is a free editable map of the whole world -- Fernando Trebien +55 (51) 9962-5409 "The speed of computer chips doubles every 18 months." (Moore's law) "The speed of software halves every 18 months." (Gates' law) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
