Talk:Machine-readable Map Feature list

From OpenStreetMap Wiki
Jump to navigation Jump to search

Maintaining this page

Discussion threads which are not active anymore are moved to the Archive.


Requirements

List of information I'd like to see in it

I said "I'd like" not every thing might do or work

  • possible tag list with possible values that are approved in the wiki, and no other
  • short and full description of tags and values
  • translation of description in different language
  • icon URL for POIs (let's dream, with convention on icon size : 16x16 32x32 64x64 or SVG )
  • recommanded other tags for one tag/value (eg natural=peak -> ele=1200)
  • Categories they belong too (just like in map feature)
  • other

Sletuffe 17:11, 18 December 2008 (UTC)

Reaching consensus

This is a list of proposals we want to reach consensus on. Please state whether you support or deny a proposal and add your reasons.

Data format

  • [Consensus] To use XML as data format for the machine-readable map feature list.
(see archive for a discussion)
Gubaer 15:12, 20 December 2008 (UTC)
  • [Proposal] To define the structure for the machine-readable map feature list formally. Gubaer 15:12, 20 December 2008 (UTC)
  • [Proposal] To define the structure for the machine-readable map feature with a DTD (not with an XML Schema nor with a RELAX NG Schema) Gubaer 15:12, 20 December 2008 (UTC)

Scoping

  • [Proposal] Out-Of-Scope: Definining a hierarchical naming schem for tag keys is out of scope
Mappers today use a kind of hierarchical naming schema for key names. ":" is the seperator between name components. Hierachical naming schemes are used for localization (name:de), for certain mapping initiatives (educamadrid:tipo), for grouping categories of tags (addr:street, addr:zip). Currently, there are not defined rules on how to define and use hierarchical names for tags.
for details see discussion below
Gubaer 15:12, 20 December 2008 (UTC)
  • [Proposal] Out-Of-Scope: Defining a type system for tag values is out of scope
OSM tags consists of arbitray name/value-pairs. In general, values are arbitrary strings. For some tags, however, only a restricted set of string values is suggested to be used. There are tags which have basically a booelan type (building, area). Others require a number and an optional unit (ele, maxweight, etc.). We will not define such a type system and the machine-readable map feature list will not include type information in tag definitions.
Gubaer 15:12, 20 December 2008 (UTC)
  • [Consensus] To restrict ourselves initially to a map feature list for accepted map features (i.e. those in the Map Feature list)
(see archive for a discussion]])
Gubaer 10:38, 28 December 2008 (UTC)

Features

  • [Proposal] To define categories (groups of tag definitions) in the machine-readable map feature list Gubaer 15:12, 20 December 2008 (UTC)
  • [Proposal] To consider categories as non-hieararchial taxonomy (a tag definition can belong to 0..* categories) Gubaer 15:12, 20 December 2008 (UTC)
  • [Proposal] To localize display names and descriptions for all objects in the machine-readable map feature list Gubaer 15:12, 20 December 2008 (UTC)
  • [Proposal] To use four live cycle states for tag definitions (proposed, rejected, accepted and deprecated) in the machine-readable map feature list Gubaer 15:12, 20 December 2008 (UTC)
  • [Proposal] Out of scope: To not include icons in the machine-readable map feature list Gubaer 12:35, 21 December 2008 (UTC)
  • [Proposal] To deploy the list on the OSM SVN from where clients can access it with a HTTP GET request Gubaer 12:19, 21 December 2008 (UTC)

Issues

Categories

  • Categories they belong too (just like in map feature)
What do yo mean with Categories? Gubaer 21:11, 18 December 2008 (UTC)
Well something close to directories. I'm trying to think of a possible use case which is putting all tag into josm preset menu. Every thing in one level seams unpractical, so I'm thinking of categories like "highway" "tracks", "water related", "mountain related", "shops", "amenities", "power", "landuse", etc. Sletuffe 21:48, 18 December 2008 (UTC)
In Tagwatch there is a basic approach to group several tags together see example. The information is stored in the templates that are added to each page. Its not the best attempt to group them but a starting point. --Etric Celine 22:27, 18 December 2008 (UTC)


If we want to have categories too it should look something like this (--Al Friede 14:02, 19 December 2008 (UTC)): 

<categorie name="highway">
	<key name="highway" icon="highway.png"></key>
        <!-- snip -->
</categorie>
Regarding categories: is it OK for everybody, that every tag belongs to exactly one category? (no tags outside of a category, no tags belonging to two or more categories)
Gubaer 21:09, 19 December 2008 (UTC)
If we can, why limit our categories to one per tag? I would implement them as repeatable elements within the tag definition (or whatever you call it).
--Hubne 02:04, 20 December 2008 (UTC)
The idea behind the categories is just to group the Tags together and make it possible to split the large list of Tags. Therefore they should only belong to one category to avoid duplication. They have nothing to do with the usage itself. Just a cosmetic help. --Etric Celine 08:17, 20 December 2008 (UTC)
Alright, there's no duplication except in the rendering/outputs, but that improves the tags' findability. As a user, I don't want to have to have to look in every category a tag might have been filed under. As a contributor, I don't want to have to waste time choosing the best single category to file my new tag. They often do belong in more than one category. That's reality. We should model it. --Hubne 23:02, 20 December 2008 (UTC)
You are right it is a hassle to find an appropriate category for a given tag. I doubt that tags are easier to find if we have them under more then one category, but I might be mistaken in this case. If more people like to have several categories for one tag then go for it. At the end it doesn't matter much. --Etric Celine 08:49, 22 December 2008 (UTC)

Icon support

I think we should not add icons to the TagDefinition. What Icon represents a specific Tag depends on the program that uses our list, not the list itself. Furthermore the icons may differ (different render rules for example). --Etric Celine 15:01, 20 December 2008 (UTC)

I second that. There are several problems regarding icons. First, it is difficult to anticipate what format, size and style applications will expect, mainly because we don't target a homogeneous community or a homogeneous plattform. Second, we would have to come up with an approach for maintaining and distributing icons in addition to the tag definition file. For applications it will be fairly easy to combine the machine-readable feature list with their own icon set. They can for instance stick to naming conventions like highway.png and highway=residential.png or maintain a mapping file which maps the tag-defs, value-defs, categories and presets from the machine-readable feature list to their icon set.
It would be good to have a set of generic icons a program can download if it have no icon in the place, but this should rather be an option. I would like to have my software populate icons as new tags are approved, but I still want the option to override this where I feel the need for it. --Skippern 12:41, 21 December 2008 (UTC)
I support that a generic icon set be an option. I'd like to get out the core machine-readable map feature list (in order to avoid feature creep) fast. Then we can think about extending it with a default icon set. Gubaer 13:20, 21 December 2008 (UTC)
I'm in favor of an information that give the icon's name, even if there is no set of icons for now. First because it's not that hard to construct the list, and it could show people discovering this file that it could also be used for that.
As of the expected size of icons, if I take kde for instance, the name is kept across all name-YxZ.ext icons that provide different size (such as peak.png, peak-16x16.png, peak.svg, etc...) and it's working quite well.
As for an assumed icon name such as "highway=residential.png" I would say the problem might be that it is not bijective (different features could share the same icon). And last, as we sometimes known, it's harder to do it later than at the beginning, and since it is not that hard to imagine a property such as icon="highway_residential".
On a personal project, I want to show on a map EVERY possible poi the osm database has (mainly for osm mappers information) and a fully automated version could be constructed out of such an xml file with icons, but not from the one without. (If the icon set is not ready by the time I do it, I'll be the one to provide a default basic quick set of icon)
Finally, I would say it's not a big deal, and I could manage an auto-assumet-set, so if you think it could lower the arise of v1 of this file, then do Sletuffe 19:54, 23 December 2008 (UTC)

Where to deploy the list ?

The list should be deployed to some node from where anybody can retrieve it with a simple HTTP GET.

Options:

  • deploy it to a decicated Wiki page on the OSM wiki.
    • Cons: clients need extract the list from the wiki page, minmal parsing necessary
  • check it into an SVN server (probably http://svn.openstreetmap.org/)
    • Pro: proper configuration management (version control)
    • Pro: easily accessible with a simple HTTP GET
  • deploy it to a web server


Suggestion: deploy it to the openstreetmap SVN Gubaer 16:33, 20 December 2008 (UTC)

Yes, deploy it as a read-only (GET-only) web service for starters. --Hubne 22:58, 20 December 2008 (UTC)


Country specific Articles

On the main page there is a section about Country specific Articles. Some thoughts about that:

  • I don't think we should use localized pages with country specific information about map features. Country specific content can be included in the ordinary pages describing map features. See for instance Tag:highway=primary which includes information specific for Switzerland, here in english but on the page with the german translation DE:Tag:highway=primary in german, on FR:Tag:highway=primary in french, and so on.
  • Even if we had country specific map feature pages we shouldn't name according to the scheme
Feature/<lang>/<key>/<country>
Feature/en/is_in_country/CH could mean
  • feature with key is_in_country and value CH, described in english
  • country (here Switzerland) specific content for feature with key is_in_country, described in english
In short, it's ambiguous.

Gubaer 17:09, 27 December 2008 (UTC)

Country abbreviations should be written in uppercase, instead of ch use CH. (see also wikipedia:ISO 3166)

Agree. Fixed it above. Gubaer 20:48, 27 December 2008 (UTC)

In combination with semantic mediawiki, informations in tables are not useable. These tables are generated with an {{#ask}}. If we need country specific semantic information, then the information have to be put into separate articles. Therefor we would need a concept how such articles are named. -- ck3d 17:57, 27 December 2008 (UTC)

Yes, if we have country specific information we want to capture with Semantic Mediawiki's semantic properties. For the machine-readable map feature list we only want to capture a few information items as semantic properties (the XML DTD in the main gives an idea of the amount). At least in this context no country specific information is captured (except, perhaps, map features which are defined by country specific interest groups for country specific mapping projects; though, there's no country specific property of such map feature either). Beside that there is still plenty of useful information which will be on map feature pages without being capture in semantic properties and for structuring this content tables will be as useful as before. I agree however that the handcrafted tables on summary pages like Map Features should be replaced as much as possible by the output of #ask. For this purpose we would also have to capture media links as semantic properties, i.e.

  • [[foto::aNameOfAPhoto]] - to shown in summary pages like Map Featurs as foto for this map feature, i.e. with an image link [[Image:aNameOfAPhoto.png]].
  • [[sampleRendering::aSampleRendering]] - dito for an image with a sample rendering

ck3d, can you given an example where country specific information which should be captured in semantic properties is maintained on the wiki today? What do you think regarding the alleged ambiguity of the schema lang/key/value/country? Do you agree this could be a problem? I didn't come up with an alternative proposal yet - did you? Gubaer 20:48, 27 December 2008 (UTC)

Examples of articles with country specific information:

Keys and values are generic. Each country has laws and this laws have to be mapped to these generic tags. Country specific articles help osm user finding the right tag.

I agree to your naming proposal fully. ck3d 21:20, 27 December 2008 (UTC)

OSM tags for routing/Access-Restrictions is an interesting example. We have been discussing an implies relationship between map features. It's part part of the preset element in the current DTD and shows up as [[implies::anotherFeature]] semantic properties in the current proposal for Semantic MediaWiki. From your example I learn that implies is country specific.

Key:highway#International equivalence shows that the element we called display-name can be country specific. The display name for highway=primary is Bundesstraße or Hauptverkehrsstraße in Germany and Hauptstrassen mit Nummerntafel (blau mit Nummer) in the german speaking part of Switzerland. Even if it was called Bundesstrasse in Switzerland the spelling would be different (there's no ß in Switzerland). The XML DTD already copes with this situation because the attribute xml:lang can be asssigned a specification for a local language_COUNTRY, i.e. de_CH, not just a language. I don't see yet, however, how we have to structure the wiki in order to allow for language and country specific map feature properties.

DE:Road signs in Germany is an example for country specific information about map features which is not to be captured in semantic properties. Gubaer 10:32, 28 December 2008 (UTC)

Others

  • Open issue: should we use types like time, date, datetime, int? And types for speed, weight, height, etc.?
Not easy to answer, In a sense it is a bit off from the original osm spirit wich doesn't forbid width=yes, but we could consider type to be "information" and editors are free anyway.
So I'll say yes, checker tools could send usefull warnings Sletuffe 21:55, 18 December 2008 (UTC)
Agree. Should be used for warnings only. It will be up to the user to decide whether he wants to enter width=yes.


  • Should we distinguish between proposed, accepted, rejected and deprecated OsmTagDefinitions?
Yes, to me only features of the same type should find their way in the same file, but I have no problem with proposed.xml, accepted.xml and rejected.xml files Sletuffe 21:55, 18 December 2008 (UTC)
I say yes, add another member that mark the tag as proposed, accepted, rejected, deprecated. This way people who like to distinguish between the tags in this way can do it and others are free to ignore this information. But it should be clear to everyone that this information is just based on the Wiki (or a few ppl in OSM) and not a set definition. --Etric Celine 21:15, 18 December 2008 (UTC)
I agree with Etric Celine. Keep it as another property rather than messing with multiple files. I'd also like to see "in use" as a value, though that may just create performance issues. --Hubne 08:32, 19 December 2008 (UTC)
  • The proposed data model does not include presets yet. Presets would be named collections of OsmTagDefinitions and OsmLabelDefinitions, possibly with fixed value for certain OsmLabelDefinitions.
  • The proposed data model does not include the following relationships between OsmTagDefinitions:
    • implied tags, i.e. tags which should not be used together with a specific tag because they not not add any valuable information
    • additional useful tags, i.e. tags which provide additional useful information in the context of a specific tag
internal ids and kind of relational xml file ? Sletuffe 21:55, 18 December 2008 (UTC)
representing a well thought over model in XML is trivial. We should discuss the concepts and the model first and reach consensus on them.
We could introduce, for instance, a OsmPreset which is identified by an unique id and - again - has a localized name and description and an icon. Then we need to express that
* it requires a specific OsmTagDefinition (users should fill in an appropriate value for the key, the application can generate a warning, if the respective tag is left empty, i.e. a name= for a restaurant)
* it suggests a specific OsmTagDefinition (users can fill in an appropriate value for the key, i.e. a oneway= for a residential street)
* it proposes a specific value for a specific OsmTagDefinition (the application will add the key/value pair, users don't have to enter it, i.e. highway=residential for a residential street)
Gubaer 22:50, 18 December 2008 (UTC)
  • I think to normalise this properly and make it more scalable, you should set up a one to many between both OsmTagDefinition and OsmLabelDefinition and a new entity Applicability or something. --Hubne 08:43, 19 December 2008 (UTC)
  • Application/online help and quick references could benefit by omitting or hiding key-value combinations for brevity. Interactive help could easily provide a mechanism to show the hidden features while a printed quick reference might omit features to conserve space. Display priority could be determined by Tagwatch popularity or some other mechanism: Is display priority something worth considering for inclusion in the machine-readable format? (It could also be collated outside the map features format which tools could optionally take as additional input.)--Sward 15:53, 20 December 2008 (UTC)
I think display priority is an issue. I've implemented a new tag editor as JOSM plugin which makes use of three tag "priorities": name/value-pairs published by OSM on their Map Features list, name/value-pairs in the current selection (of OSM primitives in JOSM), name/value-pairs in the current JOSM data set. In this plugin, "official" name/value pairs always have a higher priority than arbitrary name/value pairs. Gubaer 16:38, 20 December 2008 (UTC)



Semantic ontology proposal

Elements

Node

  • Name::node
  • Category:Element

Area

  • Name::area
  • Category:Element
Keys

Highway

  • Name::highway
  • Group::highway
  • Category:Key
Values

Highway/Trunk

  • Name::trunk
  • Has Key::highway
  • Has Element::node
  • Has Element::area
  • Category:Value

Highway/Trunk link

  • Name::trunk_link
  • Has Key::highway
  • Has Element::node
  • Category:Value

Highway/Footway

Domains

Highway/Trunk/UK

Languages

En:Highway/Trunk

  • Language::en
  • Description::Big separated street
  • Category:Language

En:Highway/Trunk/UK

  • Name::A
  • Language::en
  • Description::Class A street
  • Category:Language

Please read http://semantic-mediawiki.org/wiki/Help:Ontology_import#Ontology_format. ck3d 08:10, 26 December 2008 (UTC)

There is already a proposal for semantic properties on the main page. The article you refer to talks about importing an ontology. What existing ontology did you have in mind? Gubaer 20:56, 27 December 2008 (UTC)

This site shows how the OWL can be mapped to semantic mediawiki features:

OWL Semantic Mediawiki Term in the context of OSM map features Names are taken from above example
class category MapFeature (a kind of "root class" for our purposes) I would prefer OSM
subclass subcategory Key, Tag (or NameValuePair, or Value), Category, Preset Categories Element, Key and Value
class instance page highway (an instance of Key), highway/primary (an instance of Tag), physical (an instance of Category) Pages node, ...
datatype property property (type != page) ??? (didn't come up with relevant properties here) Name has type String (type definition)
objec property property (type = page) ??? (didn't come up with relevant properties here) Has Element has type Page. This defines a relation to another page. (type definition)
instantiated datatype property property (type != page) assignment in page displayName, description, onNode, etc.; all of them properties for instances of Key and Tag Name assignment
instantiated object property property (type = page) assignment in page ??? (didn't come up with relevant properties here) Has Element assignment
page == artilcle

This helps designing a ontology in semantic mediawiki. The goal should be exporting the data using the export function of semantic mediawiki. ck3d 11:26, 28 December 2008 (UTC)

I tried to add a third column to your table. It shows what various concepts we have been discussing so far correspond to in OWL and in Semantic Mediawiki. This is first guesss. I'm neither an expert in Semantic MediaWiki nor in OWL, but I'd like to understand how we could benefit from using Semantic MediaWiki for managing map features. I fully agree with ck3d that a standard export in RDF would be favorable over harvesting map feature information from wiki source using a wiki robot.
Gubaer 17:46, 28 December 2008 (UTC)
The fourth column shows examples from the ontology example above. See also some type examples. -- ck3d 22:44, 28 December 2008 (UTC)
In the last few days we have been discussing about "ontologies", "classes", "properties", "Semantic MediaWiki", "categories" and I felt pretty uncomfortable with all this new lingo. I therefore had a closer look into OWL and SemanticWiki and I tried to write down what I learned about them and about their relation to our project: getting out a machine-readable map feature list. The result became somewhat lengthy, i therefore put it into an independent article.

Gubaer 21:32, 29 December 2008 (UTC)

First, great work. This is a good overview about OWL and Semantic MediaWiki.
But, SMW can't define selects on a "many-valued" property, the language information won't be useable. I tried to sove that:
I separated the human data from the osm data (see example above). All language and country related information are separated into subpages. The osm data is in highway, highway/trunk and highway/trunk/UK. All description and display names are in language subpages, like highway/trunk/en and highway/trunk/UK/en. This language subpages get the semantic information from upper page can be displayed in form of a infobox. Then all language subpages have the same information.
The clou of country specific information is putting this information in a class called Domain which assignes all needed dependencies into property Has Tag (see highway/trunk/UK). The Has Tag property can also be used to define similar dependencies, see highway/footway. ck3d 23:51, 29 December 2008 (UTC)

I think I understand what you mean, but I also think, that we don't separate human data from osm data in you proposal. I don't event think this should be the goal, in the contrary, we should avoid separating ordinary wiki content from semantic annotations. Furthermore, I still believe that the naming schema highway/trunk/UK/en is not suitable because it is ambiguous.

Here's where I agree and where I suggest slight modifications:

  • there would be a language a country independent article, say Feature/highyway/primary (don't worry about the leading Feature, I come to that later), which respresents the individual and declares its language and country independent semantic properties. Except for this this declarations, the article will be empty. In this sense it only includes semantic content.
  • there would always be at least one language specific page, today usually Feature_en/highway/primary, which describes the map feature to human readers and declares language specific semantic properties. Here semantic content and human readable content is mixed. Optionally there are other language specific articles for the same map feature, i.e. Feature_en/highway/primary
  • there can be a country specific, language independent article Feature_GB/highway/primary which includes the declarations of country specific but language independent semantic properties.
  • there can be a country specific, language dependent article Feature_GB_en/highway/primary which includes the description of country specific properties in a specific language to humans. It also declares language and country specific semantic information. Example (for Switzerland which uses four languages):
    • Feature_CH_de/highway/primary would include the german display name for highway/primary used in Switzerland
    • Feature_CH_fr/highway/primary would include the french display name for highway/primary used in Switzerland
    • Feature_CH_it/highway/primary would include the italian display name for highway/primary used in Switzerland
  • back to this prefix Feature..... Rather than appending language and country specific information to a map feature title I suggest to prepend it. Here's the idea:
Titles of map feature articles always start with either
  • Feature/.... - the language and country independent article, just semantic properties, no content. Example: Feature/highway/primary
  • Feature_lang/.... - the language dependent, country independent article, semantic properties and content . Example: Feature_en/highway/primary
  • Feature_COUNTRY/.... - the language independent, country dependent article, just semantic properties, no content . Example: Feature_UK/highway/primary
  • Feature_COUNTRY_lang/.... - the language and country dependent article, semantic properties and content . Example: Feature_CH_de/highway/primary
The main advantage of this approach is, that the naming schema does not lead to ambiguities. If we had a map feature country with values UK and CH, then country and language specific articles would be named:
  • Feature/country/UK
  • Feature_UK/country/UK or Feature_DE/country/UK
  • Feature_en/country/UK or Feature_de/country/UK
  • Feature_UK_en/country/UK or Feature_CH_fr/country/UK
  • properties which refer to other map features (for instance instances of properties like Has Element in you proposal or implies in my paragraphs) are of type String not of type Page. There value is the key or the key/value-pair of a map feature, not a page title for a map feature page
    • [[Has Element::motorcar/yes]] (not [[Has Element::Feature/motorcar/yes]] or [[Has Element::Feature_en/motorcar/yes]])
    • [[implies::motorcar/yes]] (not [[implies::Feature/motorcar/yes]] or [[implies::Feature_CH_de/motorcar/yes]])


As a consequence these declarations can't be used to create links in the wiki: [[motorcar/yes]] doesn't refer to a wiki page. Therefore, these property declarations will usually be hidden from human readers by adding an empty alternative text:
  • [[Has Element::motorcar/yes | ]]
If a wiki link had to be present in the page too, we would have to add it manually for the appropriate language, i.e.
  • Has Element [[Feature_en/motorcar/yes | motorcar/yes]]
Of course, we support editors with suitable wiki templates, for instance a template {{{Implies}}}:

[[implies::{{{feature}}} | ]][[Feature_{{{lang|en}}}/{{{feature}}} | {{{feature}}}]]
Editors would use it as follows in a map feature page:

<!-- declares the semantic property and creates a link to the language dependent 
     map feature page of motorcar/yes -->
{{Implies | feature = motorcar/yes}}  <!-- language is optional, default is english -->

Gubaer 10:19, 30 December 2008 (UTC)

What content should be in page Feature_CH_fr/country/UK? A CH man speaking fr tagging in UK?

The postfix syntax is easier to implement in MW and it doesn't break the basic idea of pages and subpages. Benefits are:

  • search for highway you get highway; there are the languages and countries list
  • object properies like Has Tag works without any additional templates
I doubt that. [[Has Tag::highway/primary]] creates a "dangling" (it's not really dangling but it points to page with language independent semantic properties of highway/primary only) wiki link because all the relevant wiki content is in the pages en:highway/primary, de:highway/primary, etc.. On the other hand [[Has Tag::en:highway/primary]] probably creates a useful wiki link, but the value of the semantic property doesn't make sense.

Gubaer 15:31, 30 December 2008 (UTC)

  • template programming is simpler; handling of pagenames with / are easily handled with buildin functions of MW (see Page names at mediawiki.org)

But I have also a problem with the language postfix syntax.

My new suggestion, the combination of namespaces and subpages: de:highway/trunk/UK

I thought about that too, but I didn't follow it because some tests in the SMW sandbox showed me that #ask and #show have problems with semantic properties for pages in namespaces. I wanted to create a specific example to show you what I mean and I created this test page on the SWM sandbox. It turned out, that I was wrong - there is no problem. your example on the SMW sandbox works too. There is probably only a problem with pages whose title includes =
We should follow your proposed schema: lang:key/value/COUNTRY.
Gubaer 15:23, 30 December 2008 (UTC)

Benefits are:

  • MW supports searching in namespaces, so people get only search results from main namespace and her selected prefered language.
  • MW has buildin functions, that deals easily with namespaces (see Page names at mediawiki.org)
  • wikipedia uses the same syntax Interlaguage links

I opened a new page. Please have a look at SMW. ck3d 11:32, 30 December 2008 (UTC)

Ok. We could summarize the current proposal there, moving, extending and fixing the respective sections in the main article. Firefishy told me that he would be glad to setup a dev copy of the current OSM wiki including a SWM installation. We could use this environment to test the current proposal with a couple of map features, to test automated refactoring of the current wiki and to test generating the output for the map feature list.

Gubaer 15:38, 30 December 2008 (UTC)

Great news. That will be a great challange. -- ck3d 22:48, 30 December 2008 (UTC)


Titles of map feature pages revisited

We have come to the conclusion that map feature pages should be name according to the scheme 

 lang:key/value/COUNTRY

This holds for key an tag definitions only. Regarding feaure categories and presets we didn't come to a conclusion yet.

I therefore propose, that we continue to use pseudo-namespaces as does the current OSM wiki.

  • the namespace Key: is used for key definitions
  • the namespace Tag: is used for tag definitions
  • the namespace FeatureCategory: is used for feature categories
  • the namespace Preset: is used for presets

This proposal has the major advantage that the structure of the current OSM wiki hardly has to be changed. Only pages Tag:key=value have to renamed to Tag:key/value (because SMW can't cope with = in page titles). Everyting else remains unchanged.


Examples for pages with key definitions

  • Key:highway
  • de:Key:highway
  • Key:highway/CH
  • en:Key:highway/UK

Examples for pages with value definitions (currently OSM uses the namespace Tag:, we continue to use it in order to allow for a smooth transition)

  • Tag:highway/primary
  • de:Tag:highway/primary
  • Tag:highway/primary/CH
  • en:Tag:highway/primary/UK

Examples for pages with feature categories

  • FeatureCategory:physical
  • de:FeatureCategory:physical

Examples for pages with presets

  • Preset:residential_road
  • de:Preset:residential_road
  • Preset:residential_road/CH
  • en:Preset:residential_road/UK

Gubaer 09:37, 31 December 2008 (UTC)

The key namespace is a pseudo namespace, key is only part of the title separated by a : .

We don't need additional pages. All information can be put into pages, we named before.

old new
Key:highway=trunk en:highway/trunk
DE:Key:highway=trunk de:highway/trunk

The look an feel isn't changed. The first thing we have to change is the infobox. The infobox gets the basic information from page highway/trunk. The description will be defined in de:highway/trunk.

Presets are defined in highway/trunk/UK or in highway/footway from my example. Every tag should be able to define presets.

I'm pretty confident that this is not possible. In other words: I don't agree with this approach. It's not the tag which defines presets. A preset is, from my understanding, something independent from keys or tags (aka name/value pairs). Have a look at how JOSM defines presets. There, a preset is higher-level constructs with a name on its own. If a preset was called Residential Road this would not be the same as the tag highway/residential. Rather, the preset would describe that mappers have to tag a highway with highway/residential, that supplying a name in name is expected too, and that oneway/yes, noexit/yes, hgv/no and maxspeed might be used to further describe the residential road. A preset is a semantic concept on its own which has a rich semantic relations to keys and tags.
In OWL lingo, a preset is an individual on its own. And because we have to maintain a wiki page for each individual in Semantic MediaWiki, we must maintain semantic properties for a preset in a decicated page for this preset.
For feature categories the same arguments hold. Again, in OWL lingo a feature category is a class, a specific category is an individual. Semantic propeties for a category must be defined on its own page. For instance, the current OSM wiki uses the feature category physical informally. physical, which could be called the value of a semantic property name, is used in wiki templates for key and value definitions. Localized display names like Physical or Gegenstaendlich are hardcoded translations in summary pages. A semantic property displayName maintained on language specific pages for the feature category (as we plan to do for map features) would help. Today, there is no localized description for a feature category. Our machine-readable map feature plans to include one, however, and we should therefore provide localized descriptions of feature categories as semantic properties, i.e. in a semantic property description.
We therefore have to come forward with naming schems for pages which hold information about "classical" map featuers like keys and tags (here we agree), but also for presets and feature categories, which we want to include in the machine-readable map feature list too (that's what I go for and where we don't agree).

Gubaer 16:10, 31 December 2008 (UTC)

With presets, I interpreted implicit tags.
Presets like JOSMs presets have to defined in new pages. I agree, that such pages have to be put in another namespace, because they aren't be part of OSM tags.
With feature categories, I interpreted the groups, which are shown on the individual Key pages.
The group and category information can be hold in pages like highway. I don't know why we should define this information in another page like FeatureCategorie:physical. FeatureCategorie:physical can show a table of all tags which specify physical objects.

ck3d 16:51, 31 December 2008 (UTC)

For listing groups of features we can define new pages like en:List of all physical Features. There is no need for a special naming schema. This pages, also the map features page, don't hold any semantic information. This are display pages. ck3d 11:09, 31 December 2008 (UTC)


I just like to point to the previous discussion about the page naming scheme.

Just in case we change all wiki pages into the new scheme without the equal sign, we should write a clear statement somewhere describing the SMW problem. Otherwise this might end with others tring to change all the pages back to the old look. --Etric Celine 11:37, 31 December 2008 (UTC)

I think that we should follow a staged approach. First, we should agree on the future structure and document it. Then we should try to roll-out the new scheme including semantic properties on a dev copy of the OSM wiki for a couple of keys and tags. When we actually do what we plan to do we will probably run into problems we can't anticipate yet and it is better if we experience them on a dev copy than on the production wiki (what are the runtime effects of SMW, for instance? Any impact on response time for user, server load, hardware seizing?). If we are confident that everything is fine, we can install SMW on the production wiki, and communicate the change. A clear statement of what is going to change will help, as will a clear How-To mappers can follow in the future. This will have to be communicated as prominently as possible (Main Page, Map Features, when possible as note on top of every page, similar to what we sometimes see on Wikipedia when the Wikipedia Foundation is looking for new money; also mailing lists). Then we should begin to refactor existing content.

Gubaer 16:10, 31 December 2008 (UTC)

Thank you for your advice. Summary of that discussion:

The actual nameing schema was choosen, because MW capitalize the first character.

This soves one problem of MW but not a further problem: underlines _ in titles are replaced be spaces (example Tag:highway=motorway link)

The proposed schema has the same problems.

But with SMW we need a simpler design, so we can easily extract information out of the title (see page names). The extraced title information can be corrected with MW buildin functions (see magic words and replace). Only the title will be "wrong", displayed information and semantic data will be correct. ck3d 12:41, 31 December 2008 (UTC)



Standard ontologies

There is an ISO standard for "Geographic Information - Metadata", unfortunately not available free of charge. Does anybody have access to this document? Gubaer 22:21, 1 January 2009 (UTC)

Managing Map Features using Semantic MediaWiki

see old discussion at Talk:Wiki/Archive03#Managing Map Features using Semantic MediaWiki

value of state for tags outside the proposal process

I suggest providing (at least) something like state=unknown for key and value descriptions. There's plenty of keys documented on the wiki that haven't gone through the process. Even if you prefer not to include them in the map feature list, people will want to document them using the common templates and tools like tagwatch, and better than have people make the status up or use the default value, provide some sensible value that you can filter by. I'd even make it the default. Other options: state=none, state=invalid, perhaps state=established for tags that are in use but have not been "approved". Robx 12:08, 26 February 2009 (UTC)

Progress?

This idea seems to have gone quiet. Is anyone actively working on this right now, or did the API switch distract everyone? Jono 14:52, 22 April 2009 (UTC)

AFAIK, nobody is actively working on it. Next step would be to get SMW installed on the production wiki. Last time I asked sysadmins were rather reluctant to deploy SMW, mainly because the OSM wiki is already struggling under load. Perhaps we could give it another try and ask whether the new hardware bought this spring would be strong enough to run SMW? Gubaer 08:28, 25 April 2009 (UTC)

In order to provide a semantic web representation of the OSM Wiki, I have developed a research project (the OSMSemanticNetwork). This seems relevant to this discussion. --Andreab 22:36, 28 August 2012 (BST)

Update to reflect Wikibase

Now, we have WikiBase installed here. The project is documented at OpenStreetMap:Wikibase. We should consider a thorough update to reflect that. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 10:56, 2 December 2018 (UTC)

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Talk:Machine-readable_Map_Feature_list&oldid=1877662"