- 1 Same information as Data Primitives. Merge?
- 2 Merged done 'Elements' -> 'Data Primitive'
- 3 Area and Relations
- 4 Areas
- 5 Examples of relations in the data?
- 6 Wish example
- 7 Well previous merge was okay (Elements vs Data Primitives) but we have to use term with "data" when we talk about low-level data model
Same information as Data Primitives. Merge?
This Elements page has pretty much the same information as Data Primitives. The only slight difference is that Data Primitives talks about the underlying data representation slightly more. e.g. a segment references two node ids. OK that's information which a user (mapper) doesn't need to know, but it doesn't really hurt to know it, and apart from that, there's very little difference between the two pages.
We either should merge these pages ...or we should pick through the 'what links here' lists and carefully choose which of the two pages we should be linking to in each case, and also think about how the naming could be improved. e.g. should 'Data Primitives' be renamed 'Element Data', to give it a clearer relationship with this 'Elements' page?
Personally I'm erring on the side of a merge, but then we still need to chose which page is a better name.
- The content of Data Primitive is more for a developer ("object class"), the content of Elements for a mapper (what is to do). Both pages are not complete regarding the own theme. E.g. in Data Primitive are missing the syntaxes of id/from/to/...; id lower than 0 is possible, but causes by the parser an automatic assignment of id and so on. The informations are more in more time. The informations for a developer (what is an id?) is confusing for a mapper. In this case it seems to be better to separate. --OnTour 22:37, 19 July 2007 (BST)
- Yeah I understand the reasons why you might want it to be separate pages, but I'm thinking from a wiki organisational perspective, its easier to have the information in one place (only one page to maintain/link to). It's swings and roundabouts really, but if we are keeping them separate, then maybe 'Data Primitives' should be renamed 'Element Data'. -- Harry Wood 10:57, 20 July 2007 (BST)
- I think these pages are a good case for clean up, not sure on a merge or what. I think it might be best to leave each "element" to have it's own short page with description from both points of view. Then used as a template in each separate section of each of these pages. That way, only one section need be updated and both pages maintain their accuracy?
- Martin Renvoize 15:56, 7 December 2009 (UTC)
- I'd welcome a merge - or a clear separation which term does apply in which contect. What are Elements, compared to Data primitives, what's the difference between keys, features, tags, attributes and properties, ... See e.g. XML_Schema which still names area as one of the base types and does not list relations. --Traut 11:51, 16 January 2008 (UTC)
Merged done 'Elements' -> 'Data Primitive'
- OK so you've done that, except I would have done it the other way around. I much prefer "Element" to "Data Primitive" . We could have saved a lot of hassle be standardising this terminology years ago. There's a third word used extensively of course: "objects". I think this is quite ambiguous, even more so than "element". I've pushed for calling them "Elements" in beginner documentation such as JOSM/Guide and elsewhere off-wiki when writing about OSM. It's is a much more beginner-friendly term. It doesn't sound too geeky or technical (and lets' face it, the concept of ways & nodes doesn't need to sound geeky. They're simple!) but of the three I think "Data primitives" is the worst. it's also two words, where one would do. -- Harry Wood 22:43, 9 January 2012 (UTC)
- Moved back 'Data Primitive' -> 'Elements'
- I've moved the merged page back under the Elements name. Main advantage is that all the translations are sorted under the Elements name. (not properly merging the translations meant that I spend some time redundantly translating the data_primitives page again). I'll correct all links. The discussion also moved here. I'm doing this out of the be bold statement on the wiki help pages ;-) --Chaos99 07:59, 15 February 2012 (UTC)
- Nice one. As I say above I think 'Elements' is the best word to use (out of several possibilities) and in my opinion it's good that 'Data Primitives' has been merged here. One remaining page naming issue is that it should maybe be 'Element' not 'Elements'
- But good point about the page translations. These pages shouldn't really be moved without fixing all sorts of things.
- - Harry Wood 11:11, 15 February 2012 (UTC)
Area and Relations
Area on this article is listed as if it was an element (node, way, area). I'd recommend to use the same order as in Data Primitives: node and way, but closed way and area as special types of way.
- Done (I changed the Area heading level so that it became a subheading of Way). --Rogerhc 20:06, 14 January 2009 (UTC)
- Relations should be listed as the way to map holes in areas. The current explanation is obsolete. Rhn 20:56, 5 December 2009 (UTC)
How can you distinguish between an area and a roundabout? -- KristianThy 23:17, 12 December 2006 (UTC)
- You flag areas with a suitable key, like landuse:residential, whereas with roundabouts, you label them as highways -- Johndrinkwater 23:16, 13 December 2006 (UTC)
- Maybe we should change the "Closed way" section to reflect that? Whether a way is closed does not say at all whether it's an area or not. Take coastlines for example. They're describing an area (it's up to you whether it's the land or the sea), but the coastline ways are not closed -- they'd be too big if they were closed. And AFAIK someone is already working on removing that restriction for other polygon types too. --GabrielEbner 18:03, 24 May 2007 (BST)
Examples of relations in the data?
Can I find examples of relations in use anywhere in XML notation? Thanks. -- Mark 08:07, 8 July 2008 (UTC)
Was thinking osm REST file format to render visual data was documented . find only this poor page.You read an xml file retrun by server and have the same raw information !!! where can i find tutorial not about how parse data ( there is plenty of xml engine ) but all the meaning of attribute and atrribute value and interaction beetween other tag attribute. is there a list of predefine tag value that have been create for rendering but not for basic information ( travel) thank's
Well previous merge was okay (Elements vs Data Primitives) but we have to use term with "data" when we talk about low-level data model
- "data model" (node-way-relation-tag)
- "data primitives" (node-way-relation-tag)
Reasons behind "data ..." name (and not elements):
- OSM is free ... data (Main Page)
- we refer to contributing data Contribute map data
- we refer to data sources Category:Data sources
...and after that we call low-level quartet (node-way-relation-tag) as "Elements" to increase confusion.
- Data model/tag
- Data model/node = Template:Description/node
- Data model/way = Template:Description/way
- Data model/relation = Template:Description/relation
- The trouble with that is that "Elements" is an established term. Perhaps a different term would have been better, but that's nothing we can change with a discussion on a wiki page (an agreement on the talk list, on the other hand, would be pretty relevant). Nevertheless, I like that you started a discussion about this. I'm curious what other people think of calling this "Data elements" or something like that. --Tordanik 13:36, 7 May 2015 (UTC)
- We are using different terms in our tag documentation, this is so confusing: (node, way, area, relation). Where is "tag"? We use "feature" instead of "tag" in emplate:Description#Feature_description.
- There is a name, they are called "Elements". And especially in technical discussions, it's important to have a commonly understood term. The wiki is not just for newbies (in fact I would say that most content is mostly for power users, not newbies at all). So we don't have to dumb everything down. The page is fine as it is and easily understandable for its audience. --Tordanik 13:59, 7 May 2015 (UTC)
- We should separate technical content from content for first-time-editors. There Category:Technical - I will never refer to it from beginner guides.
- Then we should split readers as Elements (technical in Category:Technical and Elements (Beginners') in Category:Beginners' guide.
- Don't harm newbies that we are using "protocols", "xml" - they will never see/make use of it.
- BTW "protocol" is outdated term Special:WhatLinksHere/Protocol. Glossary is outdated - but I cannot fix all references by myself. Xxzme (talk) 14:10, 7 May 2015 (UTC)
articles in beginners cats should be included in Begginner's guide: