Re: [Tagging] New relation type=provides_feature
On 14 December 2012 18:41, Erik Johansson erjo...@gmail.com wrote: On Sun, Dec 9, 2012 at 2:17 PM, Markus Lindholm markus.lindh...@gmail.com wrote: Created a page on the wiki for this proposal https://wiki.openstreetmap.org/wiki/Relations/Proposed/Provides_feature What purpose does the role=entrance have when the node/way is going to be tagged building=entrance or entrance=main anyways? You mean that the role description could be left empty because it could always be deduced from tags on the member? I guess it could be possible, but I think it is much much better to have an explicit role descriptions, foremost for the benefit of the next mapper who comes along and wants to improve and edit the relation. So that he can clearly see what the intention is with the different members. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New relation type=provides_feature
On Sat, Dec 15, 2012 at 10:48 AM, Markus Lindholm markus.lindh...@gmail.com wrote: On 14 December 2012 18:41, Erik Johansson erjo...@gmail.com wrote: On Sun, Dec 9, 2012 at 2:17 PM, Markus Lindholm markus.lindh...@gmail.com wrote: Created a page on the wiki for this proposal https://wiki.openstreetmap.org/wiki/Relations/Proposed/Provides_feature What purpose does the role=entrance have when the node/way is going to be tagged building=entrance or entrance=main anyways? You mean that the role description could be left empty because it could always be deduced from tags on the member? I guess it could be possible, but I think it is much much better to have an explicit role descriptions, foremost for the benefit of the next mapper who comes along and wants to improve and edit the relation. So that he can clearly see what the intention is with the different members. The redundancy is what got me wondering what else the role could be used for, but I guess there are two parts of that. One is that it doesn't really need to be more complex and that it's probably fine if I leave the role part out. Should I use it on railways stations with subway_entrance and parkings? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New relation type=provides_feature
On Sun, Dec 9, 2012 at 2:17 PM, Markus Lindholm markus.lindh...@gmail.com wrote: Created a page on the wiki for this proposal https://wiki.openstreetmap.org/wiki/Relations/Proposed/Provides_feature What purpose does the role=entrance have when the node/way is going to be tagged building=entrance or entrance=main anyways? -- /emj ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New relation type=provides_feature
Created a page on the wiki for this proposal https://wiki.openstreetmap.org/wiki/Relations/Proposed/Provides_feature /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New relation type=provides_feature
On Fri, Dec 7, 2012 at 8:33 AM, Markus Lindholm markus.lindh...@gmail.com wrote: Created first example of provides_feature http://www.openstreetmap.org/browse/relation/2623059 Your relation type name provides_feature is too vague and could be used for all relations... Anyway, most of the mappers will prefer to create 1 node with duplicated address instead of creating 3 nodes and your relation. Please, think about contributors first. All ideas making data consumers life easier but mappers life much more complicated are failing. Pieren ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New relation type=provides_feature
Am 07.12.2012 10:27, schrieb Pieren: On Fri, Dec 7, 2012 at 8:33 AM, Markus Lindholm markus.lindh...@gmail.com wrote: Created first example of provides_feature http://www.openstreetmap.org/browse/relation/2623059 Your relation type name provides_feature is too vague and could be used for all relations... Anyway, most of the mappers will prefer to create 1 node with duplicated address instead of creating 3 nodes and your relation. Please, think about contributors first. All ideas making data consumers life easier but mappers life much more complicated are failing. I'm not sure about this. What do mappers now? Mapping a building, an entrance, address and POI-data. The additional thing would only be the relation. It's additional work for the mappers and maybe there are some who wont do this, but it will improve the quality of our data. Henning ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New relation type=provides_feature
Am 06.12.2012 23:10, schrieb Martin Koppenhoefer: 2012/12/6 Markus Lindholm markus.lindh...@gmail.com: Tags: type=provides_feature Members roles: target address entrance Comments? do you know the site relation? It might provide what you are after. I think it's the other way round. site-relation: 5 objects belong to one POI provides_features: one object includes 5 POI Henning ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New relation type=provides_feature
Am 06.12.2012 16:39, schrieb Markus Lindholm: Comments? Hi Markus, I think it's useful to have such a relation. But I would also include building-polygon, like: building entrance target address Maybe take a look at: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Buildings which seems to be quiet the same. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New relation type=provides_feature
On 7 December 2012 10:27, Pieren pier...@gmail.com wrote: On Fri, Dec 7, 2012 at 8:33 AM, Markus Lindholm markus.lindh...@gmail.com wrote: Created first example of provides_feature http://www.openstreetmap.org/browse/relation/2623059 Your relation type name provides_feature is too vague and could be used for all relations... Do you have a alternative suggestion? It's on purpose that I left the name of the relation a bit vague, so that one could expand it later with other roles besides the two (address and entrance) that I came now up with. Anyway, most of the mappers will prefer to create 1 node with duplicated address instead of creating 3 nodes and your relation. Please, think about contributors first. All ideas making data consumers life easier but mappers life much more complicated are failing. Sure, this is not basic level mapping but it builds on existing objects. And as people do more and more micro-mapping this would be a suggestion for how to do it. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New relation type=provides_feature
On 7 December 2012 11:05, Henning Scholland o...@aighes.de wrote: Am 06.12.2012 16:39, schrieb Markus Lindholm: Comments? Hi Markus, I think it's useful to have such a relation. But I would also include building-polygon, like: building entrance target address So the semantics of the building role would be that the target/POI is within the specified building? I guess there could be zero or one member with that role? But a bit redundant information as the POI should be placed within the building polygon. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New relation type=provides_feature
Dave Sutter sut...@intransix.com writes: This may be a radical suggestion for OSM but I think POIs should be removed from the map database and put in an external database. Each POI should have an address and the address is used to match the POI to the map. This can also be extended to ref tags, which are a generalized address, to add additional data to the map, such as informtion like ferry schedules. This seems like a debate about denormalized vs normal form in databases. Rather than looking at it that way, I think the questions are: 1) How do the various schemes affect our ability to use the data? 2) How do the various schemes affect the community's ability to edit the data. I think separate db vs in main db doesn't matter much for 1. The processing tools are high-leverage and written by small numbers of people. I don't think we are having a problem now. For 2, I add POIs with an editor, just like drawing everything else. So I think having a separate database would be a hindrance if the UI exposed it. If the UI doesn't expose it, it probably doesn't matter, but it seems like a lot of work, and I don't understand the gain. This may sound radical, but this is the way it is done almost everywhere else. If separate groups maintained the map and the POI list, it probably would make sense. Does that describe 'everywhere else'? pgphO9y7DtLIC.pgp Description: PGP signature ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] New relation type=provides_feature
Few days ago there was a discussion on this list with the subject Door to door routing to buildings with multiple occupants. My thoughts after the discussion was that with increasing micro-mapping we need a relation to tie different objects together. So I thought I would make a proposal for such a relation. Tags: type=provides_feature Members roles: target address entrance There has to be exactly one member with the role target, that would be the POI. There could be multiple members with the other roles. Currently I listed address and entrance as possible member roles, but the list could be open-ended. Comments? /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New relation type=provides_feature
On 06.12.2012 16:39, Markus Lindholm wrote: Few days ago there was a discussion on this list with the subject Door to door routing to buildings with multiple occupants. My thoughts after the discussion was that with increasing micro-mapping we need a relation to tie different objects together. So I thought I would make a proposal for such a relation. Tags: type=provides_feature Members roles: target address entrance There has to be exactly one member with the role target, that would be the POI. There could be multiple members with the other roles. Currently I listed address and entrance as possible member roles, but the list could be open-ended. See my previous messages for my opinions on addresses. We don't need those relations if we set each address on the the containing building/parcel/floor. A relation could be used to define which entrances connect to which POIs (shops etc.) in the building. But this is not in spirit of current indoor mapping developments. You'd rather use highway=corridor etc. to connect objects. - http://wiki.openstreetmap.org/wiki/Indoor_mapping. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New relation type=provides_feature
2012/12/6 Markus Lindholm markus.lindh...@gmail.com: Tags: type=provides_feature Members roles: target address entrance Comments? do you know the site relation? It might provide what you are after. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New relation type=provides_feature
This may be a radical suggestion for OSM but I think POIs should be removed from the map database and put in an external database. Each POI should have an address and the address is used to match the POI to the map. This can also be extended to ref tags, which are a generalized address, to add additional data to the map, such as informtion like ferry schedules. This may sound radical, but this is the way it is done almost everywhere else. Dave On Thu, Dec 6, 2012 at 7:39 AM, Markus Lindholm markus.lindh...@gmail.com wrote: Few days ago there was a discussion on this list with the subject Door to door routing to buildings with multiple occupants. My thoughts after the discussion was that with increasing micro-mapping we need a relation to tie different objects together. So I thought I would make a proposal for such a relation. Tags: type=provides_feature Members roles: target address entrance There has to be exactly one member with the role target, that would be the POI. There could be multiple members with the other roles. Currently I listed address and entrance as possible member roles, but the list could be open-ended. Comments? /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New relation type=provides_feature
On 6 December 2012 23:10, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2012/12/6 Markus Lindholm markus.lindh...@gmail.com: Tags: type=provides_feature Members roles: target address entrance Comments? do you know the site relation? It might provide what you are after. Yes, I looked at the site relation, but it has completely different kind of semantics. Created first example of provides_feature http://www.openstreetmap.org/browse/relation/2623059 /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
