Re: [Tagging] Feature Proposal - RFC - parking (redux)
On Mon, Apr 11, 2011 at 01:15, M∡rtin Koppenhoefer dieterdre...@gmail.com wrote: I am not sure if it is a good idea to put all these new tags into the amenity namespace. Amenities are general features (e.g. mapnik tries to render all of them) and the proposed tags like parking_space would in a complete mapping state clutter the map. i think, that it doesn't really matter under which key parking spaces and entrances are mapped. which one would you suggest? the parking key is already taken. If I get this right you suggest to consider amenity=parking as preliminary and to replace it with amenity=parking_space for single parking lots or groups of them, connected with relations? you can use amenity=parking_space it, but you don't have to. as stated in the proposal there are situations where it is actually not possible to do detailed mapping. that's when you should continue to use the current amenity=parking. I think this is too complicated for most cases. as stated in the proposal, it is meant for complicated parking situations, not every single parking lot. you can use it though if you like to do detailed mapping. it is definitely easier to understand, than for example the proposal for public transport which is already widely used. I suggest to continue the use of an area with amenity=parking for outline of the whole facility and optionally parking=parking_space for single or groups of actual parking spaces (plus optionally all subtags for all kind of details as suggested). as mentioned in previous mails as also in the proposal, areas for grouping don't work out. maybe it would be easier to split this up in 2 proposals: one for parking_spaces and one for complex parking relations. while you could use amenity=parking_space for itself, amenity=parking_entrance doesn't make much sense without the context of the relation which holds the information of the actual (underground) parking facility. if you want to use amenity=parking_space without a relation, you could do so, but then you could stick with amenity=parking anyway. regards, flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking (redux)
2011/4/11 Flaimo fla...@gmail.com: On Mon, Apr 11, 2011 at 01:15, M∡rtin Koppenhoefer dieterdre...@gmail.com wrote: I am not sure if it is a good idea to put all these new tags into the amenity namespace. Amenities are general features (e.g. mapnik tries to render all of them) and the proposed tags like parking_space would in a complete mapping state clutter the map. i think, that it doesn't really matter under which key parking spaces and entrances are mapped. which one would you suggest? the parking key is already taken. OK, that is a point. Well, keep it in amenity then. while you could use amenity=parking_space for itself, amenity=parking_entrance doesn't make much sense without the context of the relation which holds the information of the actual (underground) parking facility. if you want to use you could add it to nodes part of amenity=parking, and there would be no need for a relation. amenity=parking_space without a relation, you could do so, but then you could stick with amenity=parking anyway. I think we _should_ stick with amenity=parking. It is the most often used amenity tag with 546 695 occurences. You should not try to deprecate it. Instead I would welcome amenity=parking_space for the net parking area (nodes or areas, in the case of bigger parkings inside an area amenity=parking, where the name would go to this outer area) allowing for additional detail like number of lots, dedicated disabled parking, etc. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking (redux)
since there haven't been any new comments over the last couple of days i would like to start the voting for the proposal next weekend. here's the link again in case you haven't read it yet: http://wiki.openstreetmap.org/wiki/Proposed_features/parking regards, flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking (redux)
2011/4/10 Flaimo fla...@gmail.com: since there haven't been any new comments over the last couple of days i would like to start the voting for the proposal next weekend. here's the link again in case you haven't read it yet: http://wiki.openstreetmap.org/wiki/Proposed_features/parking I am not sure if it is a good idea to put all these new tags into the amenity namespace. Amenities are general features (e.g. mapnik tries to render all of them) and the proposed tags like parking_space would in a complete mapping state clutter the map. If I get this right you suggest to consider amenity=parking as preliminary and to replace it with amenity=parking_space for single parking lots or groups of them, connected with relations? I think this is too complicated for most cases. I suggest to continue the use of an area with amenity=parking for outline of the whole facility and optionally parking=parking_space for single or groups of actual parking spaces (plus optionally all subtags for all kind of details as suggested). from your proposal: * Parking spaces always have to be grouped together in a relation. In rare situations where there’s really only one single parking space that is not somehow connected to any other spaces nearby, amenity=parking should be applied. * A parking space should preferably be mapped as an area, but it is also possible to use a node. * Each single space should be mapped as a separate area. Exceptions for using one area to represent more than one space: o A lot of similar parking spaces side by side without any differing attributes and you don't want to put that much afford into it. o Spaces are just too small to map (for example for bicycle parking) o Satellite images aren't good enough and don’t allow the mapping of single parking spaces, but you can still make out separate groups of spaces. * It should not be used as a representation of one big single parking area. Highways should not cross this areas. maybe it would be easier to split this up in 2 proposals: one for parking_spaces and one for complex parking relations. cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking (redux)
service roads are not explicitly part of the proposal, but can be added to the relation. quote fro the proposal: Other elements, that are of interest, can also be added to the relation. For example: ticket vending machines, emergency phones, a.s.o flaimo Date: Tue, 22 Mar 2011 12:02:06 +1100 From: David Murn da...@incanberra.com.au To: Tag discussion, strategy and related tools tagging@openstreetmap.org Subject: Re: [Tagging] Feature Proposal - RFC - parking (redux) Message-ID: 1300755727.3701.41.camel@grunge Content-Type: text/plain; charset=UTF-8 In the case of the roads inside a parking area, there already exists highway=service, service=parking_aisle. http://wiki.openstreetmap.org/wiki/Tag:service%3Dparking_aisle Have you considered the existing use of these tags in your proposal? David ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking (redux)
On Fri, 2011-03-18 at 14:52 +0100, Flaimo wrote: ok, i see what you mean now. use amenity=parking for the whole facility, and the new tags for defining the elements inside. In the case of the roads inside a parking area, there already exists highway=service, service=parking_aisle. http://wiki.openstreetmap.org/wiki/Tag:service%3Dparking_aisle Have you considered the existing use of these tags in your proposal? David On Fri, Mar 18, 2011 at 14:09, M∡rtin Koppenhoefer dieterdre...@gmail.com wrote: Yes, but the streets that are exclusively used to access the parking space are part of the parking. The latter is what amenity=parking is about, (see also in combination with parking=surface, underground, multilevel), the first is what you want to tag. ___ 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] Feature Proposal - RFC - parking (redux)
2011/3/18 Flaimo fla...@gmail.com: just relying on a surrounding amenity=parking area without a relation also has another flaw: underground parking. basically nobody maps underground parking facilities as areas with layer=-1. all of those i have seen so far in OSM are mapped as nodes at the entrances. and that is the problem. underground parking facilities often have more than one entrance. right now, each entrance is interpreted as its own parking lot. the relation would group them together to one parking facility. Yes, it can be a possibility (and indeed to group nodes a relation different then multipolygons is needed), but I'd consider this not the better approach, as a simple area will be more useful then a relation with some nodes (and easier to map as it would be mapping as usual instead of exception/new relation type). Reasons that the area currently is not used a lot this might be: - the exact size and position are not known to the mapper (I'd suggest to map it approximately, still better then nodes) - the renderers currently don't support underground buildings in a nice way (will maybe change in the future), maybe even render them not distinguishable from surface buildings (which is discouraging). - documentation in the wiki suggests that a node is sufficient, or is not very specific. (could be changed) Btw.: you wrote that nobody mapped underground parkings as area with a layer=-1 but I found that people indeed do it. I found 90 nodes with parking='underground' (of which 4 with layer=-1) in my extract versus 40 polygons (of which 15 had layer=-1), so almost one third of the underground parkings in my region are indeed mapped as areas. This is opposite to all amenity=parking (8000 nodes vs 16000 polygons) cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking (redux)
If you have a driveway, some parts of which have a secondary lane for parallel parking or diagonal parking, and some sections of which have only a driving lane, how should this be tagged? This is a common arrangement in parks, from my experience. In some cases, the parking lane may only be large enough for one or two vehicles. ---Original Email--- Subject :Re: [Tagging] Feature Proposal - RFC - parking (redux) From :mailto:dieterdre...@gmail.com Date :Sat Mar 19 13:12:53 America/Chicago 2011 2011/3/18 Flaimo fla...@gmail.com: just relying on a surrounding amenity=parking area without a relation also has another flaw: underground parking. basically nobody maps underground parking facilities as areas with layer=-1. all of those i have seen so far in OSM are mapped as nodes at the entrances. and that is the problem. underground parking facilities often have more than one entrance. right now, each entrance is interpreted as its own parking lot. the relation would group them together to one parking facility. Yes, it can be a possibility (and indeed to group nodes a relation different then multipolygons is needed), but I'd consider this not the better approach, as a simple area will be more useful then a relation with some nodes (and easier to map as it would be mapping as usual instead of exception/new relation type). Reasons that the area currently is not used a lot this might be: - the exact size and position are not known to the mapper (I'd suggest to map it approximately, still better then nodes) - the renderers currently don't support underground buildings in a nice way (will maybe change in the future), maybe even render them not distinguishable from surface buildings (which is discouraging). - documentation in the wiki suggests that a node is sufficient, or is not very specific. (could be changed) Btw.: you wrote that nobody mapped underground parkings as area with a layer=-1 but I found that people indeed do it. I found 90 nodes with parking='underground' (of which 4 with layer=-1) in my extract versus 40 polygons (of which 15 had layer=-1), so almost one third of the underground parkings in my region are indeed mapped as areas. This is opposite to all amenity=parking (8000 nodes vs 16000 polygons) cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging -- John F. Eldredge -- j...@jfeldredge.com Reserve your right to think, for even to think wrongly is better than not to think at all. -- Hypatia of Alexandria ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking (redux)
I would map the driveway as a way with highway=service + service=driveway, then areas of parallel or diagonal parking I would map as an area with tags that depend on how this proposal turns out. However there is another proposal [1] which would suggests tagging the appropriate section of the driveway itself with a tag parking:lane=both/right/left. That seems to have about 17000 usages. Well maybe I would tag it that way instead of according to this proposal, I'm not sure. -Josh [1]: http://wiki.openstreetmap.org/wiki/Proposed_features/parking:lane On Sat, Mar 19, 2011 at 3:57 PM, j...@jfeldredge.com wrote: If you have a driveway, some parts of which have a secondary lane for parallel parking or diagonal parking, and some sections of which have only a driving lane, how should this be tagged? This is a common arrangement in parks, from my experience. In some cases, the parking lane may only be large enough for one or two vehicles. ---Original Email--- Subject :Re: [Tagging] Feature Proposal - RFC - parking (redux) From :mailto:dieterdre...@gmail.com Date :Sat Mar 19 13:12:53 America/Chicago 2011 2011/3/18 Flaimo fla...@gmail.com: just relying on a surrounding amenity=parking area without a relation also has another flaw: underground parking. basically nobody maps underground parking facilities as areas with layer=-1. all of those i have seen so far in OSM are mapped as nodes at the entrances. and that is the problem. underground parking facilities often have more than one entrance. right now, each entrance is interpreted as its own parking lot. the relation would group them together to one parking facility. Yes, it can be a possibility (and indeed to group nodes a relation different then multipolygons is needed), but I'd consider this not the better approach, as a simple area will be more useful then a relation with some nodes (and easier to map as it would be mapping as usual instead of exception/new relation type). Reasons that the area currently is not used a lot this might be: - the exact size and position are not known to the mapper (I'd suggest to map it approximately, still better then nodes) - the renderers currently don't support underground buildings in a nice way (will maybe change in the future), maybe even render them not distinguishable from surface buildings (which is discouraging). - documentation in the wiki suggests that a node is sufficient, or is not very specific. (could be changed) Btw.: you wrote that nobody mapped underground parkings as area with a layer=-1 but I found that people indeed do it. I found 90 nodes with parking='underground' (of which 4 with layer=-1) in my extract versus 40 polygons (of which 15 had layer=-1), so almost one third of the underground parkings in my region are indeed mapped as areas. This is opposite to all amenity=parking (8000 nodes vs 16000 polygons) cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging -- John F. Eldredge -- j...@jfeldredge.com Reserve your right to think, for even to think wrongly is better than not to think at all. -- Hypatia of Alexandria ___ 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] Feature Proposal - RFC - parking (redux)
2011/3/18 Flaimo fla...@gmail.com: since i wasn't the only one wondering on how to map individual parking spaces, i took the chance to write my first proposal. it's ready for comments and can be found here: http://wiki.openstreetmap.org/wiki/Proposed_features/parking While I agree that mapping singular parking spaces is a valid desire, I don't agree with the proposed tagging. To avoid confusion (and for simplicity) I'd encourage to use a new tag for single lots. It is ridiculous to add capacity=1, and other subtags on every single parking space inside a bigger parking area. Instead amenity=parking would be used for the whole parking facility and another (new) tag like parking=lot (or whatever english wording is suitable) would be used to indicate single spaces. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking (redux)
Am 18.03.2011 11:54, schrieb Flaimo: since i wasn't the only one wondering on how to map individual parking spaces, i took the chance to write my first proposal. it's ready for comments and can be found here: http://wiki.openstreetmap.org/wiki/Proposed_features/parking My comments/suggestions: I do not see a good reason to use amenity=parking on the individual parking spaces within a larger parking area. Instead, I would prefer to keep using amenity=parking a closed way that covers the entire parking area and contains the individual parking spaces. I would then use a different tag for individual parking spaces (parking_lot=yes if there are no better ideas). Besides of requiring one tag less per feature, it would not contradict current usage of amenity=parking, and would make it a bit easier for renderers that want to ignore individual parking spaces (which is a sensible cartographic decision for many use cases). I also suggest to allow nodes for parking spaces. Areas are the obvious choice *if* you use high-res satellite imagery. But without imagery, it still makes sense to map individual parking spaces for special interest groups from surveyed information. This is where a node is the appropriate solution until more detailed data becomes available. Accepting both nodes and areas to accommodate different detail levels of data is good practice for other features, e.g. those in the shop and amenity categories. Tobias Knerr ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking (redux)
i think you misread the proposal. you don't tag any capacity tags on a single parking space. and all common properties can also be defined in the relation, so no need to tag every single space either. Quote: General tags ... defined in the relation are inherited by the elements inside the collection as long as not mapped otherwise. the naming for single spaces, as also the usage of the existing amenity=parking is already in discussion in the comments of the proposal. regards, flaimo On Fri, Mar 18, 2011 at 12:41, M∡rtin Koppenhoefer dieterdre...@gmail.com wrote: While I agree that mapping singular parking spaces is a valid desire, I don't agree with the proposed tagging. To avoid confusion (and for simplicity) I'd encourage to use a new tag for single lots. It is ridiculous to add capacity=1, and other subtags on every single parking space inside a bigger parking area. Instead amenity=parking would be used for the whole parking facility and another (new) tag like parking=lot (or whatever english wording is suitable) would be used to indicate single spaces. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking (redux)
2011/3/18 Flaimo fla...@gmail.com: i think you misread the proposal. you don't tag any capacity tags on a single parking space. and all common properties can also be defined in the relation, IMHO no need for a relation, as the amenity=parking around it already gives you this information. You would need the capacity if you won't differentiate between area (several parking spaces) and space (one parking space), which I'd encourage (it is the same feature, just differing in size/capacity, so better use just one tag instead of 2 IMHO). the naming for single spaces, as also the usage of the existing amenity=parking is already in discussion in the comments of the proposal. Yes, I've seen this and I encourage you to take it under account. Also have a look what Tobias wrote above, which I support completely. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking (redux)
Date: Fri, 18 Mar 2011 12:53:01 +0100 From: Tobias Knerr o...@tobias-knerr.de To: Tag discussion, strategy and related tools tagging@openstreetmap.org Subject: Re: [Tagging] Feature Proposal - RFC - parking (redux) Message-ID: 4d83479d.5090...@tobias-knerr.de Content-Type: text/plain; charset=ISO-8859-1 I do not see a good reason to use amenity=parking on the individual parking spaces within a larger parking area. Instead, I would prefer to keep using amenity=parking a closed way that covers the entire parking area and contains the individual parking spaces. I would then use a different tag for individual parking spaces (parking_lot=yes if there are no better ideas). Besides of requiring one tag less per feature, it would not contradict current usage of amenity=parking, and would make it a bit easier for renderers that want to ignore individual parking spaces (which is a sensible cartographic decision for many use cases). my original version used new tags for all three elements, but a user in the comments suggested to explicitly use amenity=parking for compatibility reasons and to slowly force renderers to adapt this mapping scheme. I also suggest to allow nodes for parking spaces. Areas are the obvious choice *if* you use high-res satellite imagery. But without imagery, it still makes sense to map individual parking spaces for special interest groups from surveyed information. This is where a node is the appropriate solution until more detailed data becomes available. Accepting both nodes and areas to accommodate different detail levels of data is good practice for other features, e.g. those in the shop and amenity categories. good argument. i changed the proposal accordingly. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking (redux)
On Fri, Mar 18, 2011 at 13:27, M∡rtin Koppenhoefer dieterdre...@gmail.com wrote: 2011/3/18 Flaimo fla...@gmail.com: IMHO no need for a relation, as the amenity=parking around it already gives you this information. You would need the capacity if you won't differentiate between area (several parking spaces) and space (one parking space), which I'd encourage (it is the same feature, just differing in size/capacity, so better use just one tag instead of 2 IMHO). i don't agree with that, because only the physical areas where, for example a car, can park is a parking space/area, but not for example the street itself. the current mapping scheme by using a big area over the whole parking facility is just inaccurate and comes from times where mappers didn't have satellite images available and couldn't accurately map such areas. what you actually would need is a landuse=parking and a amenity=parking. the first describes the whole parking facility, the second the actual parking spaces. take this parking lot for example: http://osm.org/go/0JhJenH8g-- . how should a renderer or routing programm know, that those individual parking spaces actually are one big lot? that's the whole purpose of the proposal, so a more accurate mapping of the individual elements is possible. if you want to use the current inaccurate mapping scheme you can still do that by not using don't use parking_type and a relation. regards, flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking (redux)
2011/3/18 Flaimo fla...@gmail.com: On Fri, Mar 18, 2011 at 13:27, M∡rtin Koppenhoefer dieterdre...@gmail.com wrote: 2011/3/18 Flaimo fla...@gmail.com: i don't agree with that, because only the physical areas where, for example a car, can park is a parking space/area, but not for example the street itself. Yes, but the streets that are exclusively used to access the parking space are part of the parking. The latter is what amenity=parking is about, (see also in combination with parking=surface, underground, multilevel), the first is what you want to tag. the current mapping scheme by using a big area over the whole parking facility is just inaccurate and comes from times where mappers didn't have satellite images available and couldn't accurately map such areas. no. It is not mapping the actual parking space but the whole parking facility. what you actually would need is a landuse=parking and a amenity=parking. the first describes the whole parking facility, the second the actual parking spaces. no, you don't need a landuse, see above. take this parking lot for example: http://osm.org/go/0JhJenH8g-- . how should a renderer or routing programm know, that those individual parking spaces actually are one big lot? They can't know, because the mapping is not correct. But pointing at mapping errors does not prove anything. the proposal, so a more accurate mapping of the individual elements is possible. Yes, and as said in my first post, I second this, but encourage you not to misuse amenity=parking for it but rather use something like parking_space or whatever. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking (redux)
On 18.03.2011 13:33, Flaimo wrote: my original version used new tags for all three elements, but a user in the comments suggested to explicitly use amenity=parking for compatibility reasons and to slowly force renderers to adapt this mapping scheme. I disagree with that user's idea of forcing renderers to implement a new feature by breaking existing rendering rules. If it is possible to introduce tagging for individual parking spaces without changing the usage of existing tags such as amenity=parking (and it is easily possible by using separate tags), then it should be done. Renderers will adapt their rendering rules if they want to show individual spaces, and don't need to change them if they are not interested in showing individual spaces. And that's exactly how it should work. As explained by Martin, amenity=parking traditionally marks an entire parking facility, including not only parking spaces, but also infrastructure within the facility. Thus it provides a higher level of abstraction which is still useful even when you map individual spaces. Additionally, the availabilty of an enclosing amenity=parking area could make the use of a relation optional in many cases, enabling a visually more intuitive editing style. As mentioned on the site proposal page, it is not necessary to use a site relation if all the elements contained within an area (the perimeter) belong to the site, and no elements of the site exist outside the area. I also suggest to allow nodes for parking spaces. [...] good argument. i changed the proposal accordingly. Nice, thanks. Tobias Knerr ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking (redux)
ok, i see what you mean now. use amenity=parking for the whole facility, and the new tags for defining the elements inside. that only works without a relation as long as you only have one logical parking lot that's not split up in different areas. but parking lots, on airports for example, are often separated by official roads which are not part of the parking lot. therefore you would map two amenity=parking areas and then you need the relation anyway. and what about situations where parts of the area are not part of amenity=parking? exclude them by creating a multipolygon relation for that spot? doesn't make things easier. also inheritance of properties would be more complicated in the long run. that's exactly why the relation=site proposal was written (which, according to the comments, is already used a lot) and why i based my proposal on that. i'll mention your concern in the comments of the proposal and let's see what the other users think. on terms of the interpretation of amenity=parking. i don't see why the purpose couldn't be further refined by an additional tag. it is done this way for highway=service + service=* for example. regards, flaimo On Fri, Mar 18, 2011 at 14:09, M∡rtin Koppenhoefer dieterdre...@gmail.com wrote: Yes, but the streets that are exclusively used to access the parking space are part of the parking. The latter is what amenity=parking is about, (see also in combination with parking=surface, underground, multilevel), the first is what you want to tag. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking (redux)
2011/3/18 Flaimo fla...@gmail.com: ok, i see what you mean now. use amenity=parking for the whole facility, and the new tags for defining the elements inside. +1 that only works without a relation as long as you only have one logical parking lot that's not split up in different areas. but parking lots, on airports for example, are often separated by official roads which are not part of the parking lot. therefore you would map two amenity=parking areas and then you need the relation anyway. sometimes, given that these segregated parkings are indeed _one_ Parking (often while all beeing parkings of the same airport, they would be distinct parkings where routing to distinct places would also be desirable). You don't need a site relation in these cases anyway, you can do with type=multipolygon. and what about situations where parts of the area are not part of amenity=parking? exclude them by creating a multipolygon relation for that spot? yes, of course. That's the same for every features. Multipolygons are for grouping outer ways as well as for subtracting enclaves. They are an object type suited for mapping one feature which is geometrically split up into different pieces. doesn't make things easier. also inheritance of properties would be more complicated in the long run. I don't understand this. Inheritance of properties is implicit in multipolygon relations. that's exactly why the relation=site proposal was written (which, according to the comments, is already used a lot) and why i based my proposal on that. the site relation is indeed used a lot (around 128.000 times) but IMHO needed only for details like where is the ticket office, where is the main entrance, which would be a suggested label position (render hint), etc. and there is no application that I know of (in contrary to multipoly) which takes site relations into account. on terms of the interpretation of amenity=parking. i don't see why the purpose couldn't be further refined by an additional tag. it is done this way for highway=service + service=* for example. in highway=service + service=* all ways remain still types of service, while in your suggestion you would shift the meaning from parking facility (including streets and ticket machines, lift-gates, etc.) to parking space for a vehicle. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking (redux)
On Fri, Mar 18, 2011 at 15:51, M∡rtin Koppenhoefer dieterdre...@gmail.com wrote: 2011/3/18 Flaimo fla...@gmail.com: I don't understand this. Inheritance of properties is implicit in multipolygon relations. take a look at the example for the car rental: http://wiki.openstreetmap.org/wiki/File:Big_car_rental_service.png it's about inheriting general values defined in the relations and subrelations. i think with just a multipolygon this is not possible. but i actually consider multipolygon relations more complicated to understand than the site relation. just relying on a surrounding amenity=parking area without a relation also has another flaw: underground parking. basically nobody maps underground parking facilities as areas with layer=-1. all of those i have seen so far in OSM are mapped as nodes at the entrances. and that is the problem. underground parking facilities often have more than one entrance. right now, each entrance is interpreted as its own parking lot. the relation would group them together to one parking facility. the site relation is indeed used a lot (around 128.000 times) but IMHO needed only for details like where is the ticket office, where is the main entrance, which would be a suggested label position (render hint), etc. and there is no application that I know of (in contrary to multipoly) which takes site relations into account. labeling position is not mentioned in the parking proposal and i also don't think that it is important right now. it would be a nice benefit, though. also the site relation for parking could be part of a bigger site relation which would represent a consistent mapping stile. that nobody interprets it is not the mappers or the mapping schemes fault. sticking with an older and, in my opinion, less suitable method, because map and routing programmers don't keep up with new developments, shouldn't be the way to go. otherwise we still wouldn't have the new public transport scheme, which also is also used a lot and still isn't interpreted in mapnik. regards, flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
