[Tagging] Tagging Governance
Hi all, I have got into the duty to talk about tagging governance on the SotM and I would like to develop that opportunity towards something that is rather helpful in the long term. To ensure that I am on the right track and not unintentionally after a personal agenda I would like to ask you to comment on the findings so far listed below. This is a copy of the message to talk@. As a courtesy to your fellow mappers I suggest to keep the discussion in one thread and reply there. Imperfect Flow of Information Although many parts of the OpenStreetMap project are well translated, the tagging documentation has substantial deficiencies. Over a random sample of 10 tags the number of declared languages varies between 2 and 18, but only few are complete and up to date (sample: 2 of 10 for German, 3 of 10 for French). Another kind of imperfect information flow is that tag definitions can be changed on the wiki page long after the tag is in widespread use. The converse case that a tag is introduced without any documentation is also happening. While this happens by ordinary users usually slow enough to make sense of the added data, an import or organized edit might be able to substantially skew the de facto meaning of a tag, regardless whether it is in widespread use, documented, both, or none. More Structure needed The translation issues have been conflated with a different problem: Different features may look very different between regions. E.g. highway=primary and highway=unclassfied versus highway=track need different sets of examples in Germany and the urban US on the one hand and Iceland or rural Africa on the other. It is easy to mix this with the translation into the predominant language in the area, but the tagging challenges in Belgium, Canada, and Niger are substantially different, although all three countries happen to have French as official language. Conversely, there is no sane reason to change tagging rules every block of houses in Brussels. Additionally, people often have different search terms than the British English tag names or their translations, and the wiki search engine is infamous for its bad performance. Having explicit keywords to direct the attention of a mapper to the list of possibly fitting tags might help. A substantial problem source of the concept of proposals is that it interacts with lots of tags in a nontrivial way and is practically never properly applied to all affected tag definitions. A proposal currently is an extra page although it should have much more an impact like a Git commit, grouping changes across various tag definition pages in a single changeset. Legitimacy and Governance What legitimation has a process if only a handful of people have that have the time to write mails on a mailing list and to write wiki pages are involved? In particular, if the proposals end up as being full of contradictions or vague terms and leave necessary answers undefined. Yet these still are the people that have shown the necessary long-term endurance to assure maintenance and that do the work. Thus every change to replace processes with better processes must be geared towards broadening not narrowing the base of long-term maintainers. Conversely, I fully understand mappers that are wary of sudden changes in the rendering or the access to tags in edting software. A lot of people whould probably appreciate to better understand what happens on the way from a tag discussion to a final change in the renderer or editing software. These processes are not secret, but often under-documented. Again, the various discussion channels and the lacking information flow contribute to the bad mood. Even worse, the ratio between people and channels means that evil or just plainly incompetent people could easily take over some channels and contribute substantially to the confusion. Good ideas how to redirect people and close down some of the channels (e.g. wiki discussion pages) might be worth pursuing. On top of that the wiki history is so much less helpful than what developers are nowadays used to from version control systems that borrowing methaphors and paradigms from there to the tag documentation is worth consideration. This hopefully helps to foster that the authors of the documentation and the mappers using a tag actually agree on its meaning. Best regards, Roland ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] The actual use of the level tag
Hi Tobias, thank you for keeping the discussion. One extra thing I have just learned is that non-numerical level refs are not-so-uncommon in the US, hence should be covered by a tool to be helpful there. > I do not want to sound so combative or negative here - to reason > for why a new tag may be useful, I just need to describe the problem. > I want us all to be on the same page. I am still not yet sure about where we are starting from and where we are going to. Typical examples would be for me: https://openlevelup.net/?l=-2#20/55.68178/12.55260 https://openlevelup.net/?l=-0.5#18/51.23423/6.77858 I do consider both to be SIT compliant. In both cases there is no building outline (at least no canonical one; footprint on the street level is different from the total of passenger visible area is different from the area covered by concrete foundations and so on). In particular, there is no object that could or should carry tags applying to all involved objects. Given that one often cannot even decide for a station complex whether it is one or multiple stations, there often cannot be a global object responsible for the structure as a whole. The half numbered levels for the small mezzanines fit intuitively into the whole level order -2, -1, 0 as signposted by the operator. Thus there also is no need for an explicitly declared order on a global object. There is an obvious order of the levels there by reading them as fractional numbers. And all tools I am aware of (OpenLevelUp, JOSM, OpenStationMap and others) can work with this sequence of levels. So I do support to have new extra tags that keeps whatever important but yet missing information. But I do not see yet why there should be a mapping of levels to integers at all. Clarifying this point probably would help to understand whether there is a preferred choice for 0, whether missing levels need to be modeled at all and what to do with small mezzanines: Shall they trigger to have a gap for them in a potentially large building complex? Can disjoint mezzanines between larger levels get the same level designation to keep the index dense? Best regards, Roland ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] The actual use of the level tag
Hi Tobias, we have here in Wuppertal, Germany at least three indoor-tagged structures that have street level entrances at multiple levels, making "street level" a not-at-all defined concept. In case of the university e.g. the main entrance is on level 7, and street level entrances range from levels 2 to 10. I am also aware of dozens of buildings across Europe with "street level entrance" on multiple levels. I am also a bit surprised: a common interpretation of the text of https://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging (which is where https://wiki.openstreetmap.org/wiki/Key:level refers to) is that the level tag keeps the level numbering scheme of the operator whenever it is sufficently tied to numbers (that's almost always the case). That had also been consensus in the SotM 2016 indoor session and has since then been used for thousands of stations in at least France and Germany. What about just rewriting the section "Values" of the page https://wiki.openstreetmap.org/wiki/Key:level This affects the subsection "Numercial Values", but the subsection "String values" is misleading as well. There are only 118 objects with indoor=level in the world, and only 7 of them have a "name" and a "level:ref" tag, and only 2 use the tags as intended on the wiki pages (the other use the name for the whole structure). Best regards, Roland ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [OSM-talk] Feature Proposal - RFC - Mapping disputed boundaries
Hi all, a much simpler approach is to look into the respective constitution. The Ukrainian constitution defines the state's territory in article 133. Other countries, like Germany do so as well, and Ireland does or has done so. France does not define its terriotry in the constitution, and the UK has AFAIK no constituation. Probably in both countires laws exist. Thus I suggest to create a relation comprising the regions mentioned in that said article. It should hold the various name tags and a distinct tag (not "boundary", "admin_level", or "source") to indicate that it is a boundary according to the consitution, e.g. "legitimation=constitution" (and "legitimation=national_law" if not declared by the constitution). Countries where the constitution conincides with the de-facto border can just get the tag. For Cyprus and Western Sahara, I have been unable to find the relevant documents. I'm cautiously optimistic that they can be modeled in the same way. Given that there is at most one constiution per country, that those are designed to change infrequently and most countries are expected to conincide, this allows to add no-nonsense data without opening a can of worms. Best regards, Roland ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Public Transport Timetables Proposal RFC
Hi, Hint: you may get more qualified feedback if you use the talk-transit@ mailing list. This tagging@ list is a generalist mailing list intended to gather people with a passion to write mails. One thing we could investigate is some sort of indication whether a bus or train route tagged in OSM is frequent, infrequent, or rarely used - but we'd have to find a classifier for this that is vague enough to not change twice a year, and precise enough to still be useful (and e.g. draw "infrequent" lines with a dashed color on a public transport map or so). A thing that would work in at least the Netherlands, Belgium, Switzerland, Austria, Germany, France, Great Britain, Denmark, Sweden, parts of the US (and probably numerous other countries I never have visitied): Mark route reations with opening_hours=... for the operation times service_pattern=dense for at least 6 services per hour on workdays from typical local breakfast time to one hour after typical local dinner time, 3 services per hour on saturdays, sundays, and bank holidays service_pattern=clock_face if the service is subject to clock face scheduling service_pattern=all_day if there is at least about one service per hour all over the day (again berakfast to after dinner) service_pattern=special if the service has limited operation times (school buses, peak hour services, stadium extra service, night buses, and so on) interval=... as it exists. It is unfortunately ambiguous whether peak interval or longest interval is indicated, but people may like to continue information here Using pairs of opening_hours:evening=... service_pattern:evening=... or opening_hours:evening=... interval:evening=... with this or other suffixes can be given as advice for people who want to refine the information further. Note that this information is usually stable for decades: It derives from the number of rolling stock divided per travel time. Lifetime of rolling stock is typically between 15 years (buses with internal combustion engines) and 25 to 50 years (trainsets), and 1:1 replacements are also quite common. The rationale for breakfast to one hour after dinner is that both business and touristical activity take place within that time window. People outside that time window will know how and where to get better adapted and more precise information. Bye Roland ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Documentation issues of PT tagging schemes
Hi, What I would like to see is how to map a Public Transport Route in version 3 .. that has the bear minimum of things to have and the rules that make the route valid. This is where the problem sits; the point of view of what a route is vary wildly. Few people are even willing to pinpoint and tell their personal definition. Things that exist under the notion of route: - Urban bus/tram/subway services (many stops, many departures, route taken always or almost always the same, route through the street grid practically fixed, often unchanged for years to decades) - Peak services, special routes to depot, school services (few departures, many stops, also many route variants, frequently changing, making it impractical to route them all) - Hail bus services: the bus is promised to serve a certain street and stops on hail (many departures, route taken always or almost always the same, route through the street grid practically fixed, often unchanged for years to decades) - Urban and regional train lines (many stops, many departures, route and platforms fixed). Those routes are often in parts or completely land marks. - Long distance train lines (many stops, many departures, route and platforms may or may not vary, can stop at a different platform of the same station for operational reasons) - Long distance bus services (few stops, few departures, route between stops often changing on the fly) - Ferry lines (often only two stops, completely different infrastructure) Further kinds of routes may exist. For example, some communties use virtual metro lines that connect station node to station node. This is most often because the communties lack the ressources to map the actual underground structures. I personally map only urban bus/tram/subway services and urban and regional train lines (and do not delete other routes). For these services it is sane to have marked the stops and the route on the grid. The route on the grid is straightforward: this is in any PT scheme a sequence of way members that together form a continuous trajectory. Hail sections get a special role for these members. The stop part is more tricky. I personally add one element for each stop where the bus/train is calling, using the role "platform". The member element should have the tag "name" set to ensure meaningful usage and pain-free editing of the route. The minimum required tags on the relation are "ref=", somtimes "name=", and "type=route" + "route=bus" for buses. Please do not forget that a more detailed explaination fits better on the transit list https://lists.openstreetmap.org/listinfo/talk-transit I would suggest to continue the discussion there, but Ilya has for unknown reason fear of the talk-transit list. It makes sense to give him an easy opportunity to answer. I read Ilya's proposal such that he wants to feature the virtual metro lines, at the expense of mandating to map hail services as empty relations. But it would be better if he tells us himself. Best regards, Roland ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Documentation issues of PT tagging schemes
Hi, This would not be the bells and whistles method, but the bread and water method. The basics that would have the routing working and the map displaying things. See https://wiki.openstreetmap.org/wiki/Tag:highway%3Dbus_stop and https://wiki.openstreetmap.org/wiki/Tag:railway%3Dplatform Both wiki pages are up to date and pretty prefect. "Up to date" means that more than 90% of all public transport objects are mapped that way. From a semantic way, it would only be necessary to drop a few words for - tram stops without a platform - subway stations: if the underground structure is not known then you should map at least "railway=station" + "name=" and all entrances And a decent mapping scheme would be complete. I have written routers for passengers, routers for the operators, a route display tool https://overpass-api.de/public_transport.html and a JOSM plugin for editing public transport. Bottom line: Nobody, really nobody needs relations of type stop_area, stop_area_group, route_master, network, and stop_position information. This is also the thing I do not like about the proposal: it is again cluttered with also that complexity, mixing the important with the unimportant and the commonplace with the obscure. The upside is: public transport is in a much better state than all the discussion contributions suggest. Public transport operators from five continents are now voluntarily using OpenStreetMap data for a wide range of purposes, because it is good enough to do so. For discussing details I suggest the relevant mailing list https://lists.openstreetmap.org/listinfo/talk-transit It is purely about public transport and has some hundreds of subscribers. On this mailing list "tagging" here, between golf courses and detached houses relatively few people will find this discussion in the long run. Best regards, Roland ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
