Re: [Tagging] Use of a site relation for grouping parking spaces
Alessandro: good work! Andy T.: site relations are used for onshore wind farms as the 'farm' is the collection of turbines and not the areas in-between which are still used for farming, etc. It _might_ apply to a solar farm where fields of panels are not contiguous, but generally we have used a site boundary polygon for a security fence. On Tue, Dec 3, 2019 at 10:58 PM Alessandro Sarretta < alessandro.sarre...@gmail.com> wrote: > Thank to everybody, the text has been changed (by Mateusz Konieczny) > accordingly: > > https://wiki.openstreetmap.org/w/index.php?title=Tag:amenity%3Dparking_space&diff=1928515&oldid=1890083 > > Ale > > On 03/12/19 23:42, Martin Koppenhoefer wrote: > > > > sent from a phone > > > >> On 3. Dec 2019, at 20:32, Joseph Eisenberg > wrote: > >> > >> I doubt it is useful to use a type=site relation with parking_space > features at all. But your proposed rewording would be an improvement. > > > > I mostly agree, although one could construct situations where you might > want to relate e.g. parking ticket machines or surveillance cameras > (located outside the parking and represented by nodes) to specific > parkings. Generally it doesn’t seem helpful to require a site relation, in > most cases it wouldn’t add anything. > > > > Cheers Martin > > ___ > > Tagging mailing list > > Tagging@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/tagging > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Use of a site relation for grouping parking spaces
>> On 03/12/2019 18:59, Alessandro Sarretta wrote: >> Should we maybe rephrase the sentence "Parking spaces *always have to* >> be grouped together in a site relation tagged with type=site + >> site=parking." in something like "Parking spaces *can* be grouped >> together in a site relation tagged with type=site + site=parking."? + 1 Completely agree; as long as we speak about free tagging system we shall impose rather minimal restrictions - just imagine a beginner mapping fellow who intends to map a parking correctly; the current wording does not make it easier. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting result - Pedestrian lane
Thank you Markus for this summary. I think that the issue of having a good way to describe marked lanes on the road dedicated for people to walk is still there. In my opinion it needs a more extensive discussion and some tagging and graphic examples to show simple and complex application. As an example, I'm thinking about detailed mapping for pedestrian (or even people with disabilities) that might need additional information. Information on width could help to understand if that footway is safe for wheelchair, or colour could help visually impaired people (or even smoothness values that can differ from the main road). In an example with pedestrian lanes (or let's call them footway lanes, or even sidewalk lanes, ...) on both sides of a two-ways road we could have on the left side a 1m-wide lane, on the right side a red lane. How should we map them? pedestrian_lane=both pedestrian_lane:left:width=1 m pedestrian_lane:right:colour=red or something like footway=lane footway:left:width=1 m footway:right:colour=red And in case on the left we have a shared cycle/foot lane? cycleway:left=lane pedestrian_lane=left segregated=no or cycleway:left=lane footway:left=lane segregated=no I think discussing of specific examples could help us clarifying which solution is better (or more usable). m2c Ale On 03/12/19 21:35, Markus wrote: Dear all, The voting on the proposal for a new key pedestrian_lane=* for lanes designated for pedestrians is over. 8 people voted for the proposal, 5 against it and 1 person abstained. This is an approval by 62%, which is below the required 75% majority. Therefore the proposal has been rejected. https://wiki.openstreetmap.org/wiki/Proposed_features/Pedestrian_lane The following reasons for opposing the proposal were given: - footway[:left/right]=lane should be used instead of the proposed pedestrian_lane=left/right/both. (mentioned twice) - More discussion is needed. (mentioned twice) - Disagreement with the definition of sidewalk=* being a raised or otherwise physically separated footpath at the side of a road. (mentioned once) In my opinion, footway[:left/right]=lane isn't a good idea for the following reasons: 1. footway=lane is a contradiction, as a lane (part of a road/path) isn't a footway (separate path). 2. sidewalk=left/right/both and footway[:left/right]=lane would have two different syntaxes, which were confusing. 3. lane would be the only value which were a departure from the usual tag syntax where the value is variable and the key remains constant. Many thanks to the (unfortunately rather few) people who took part in the vote. Best regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal – RFC – notary
The proposal looks good as a way to tag that a notary is at another feature such as a law office. You might also mention that office=notary can be used for a place that is only a notary. https://wiki.openstreetmap.org/wiki/Tag%3Aoffice%3Dnotary -Joseph Eisenberg On Tue, Dec 3, 2019 at 12:27 PM Sebastian Martin Dicke < sebastianmartindi...@gmx.de> wrote: > Hi, > > > I often found offices of lawyers, which are notaries, too, and office > sharings of lawyers and notaries. To tag this appropriate, I wrote a > proposal: > > > https://wiki.openstreetmap.org/wiki/Proposed_features/notary > > > Definition: Notary services offered by a lawyers office > > > Regards > > > Sebastian > > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal – RFC – notary
sent from a phone > On 3. Dec 2019, at 21:27, Sebastian Martin Dicke > wrote: > > I often found offices of lawyers, which are notaries, too, and office > sharings of lawyers and notaries. To tag this appropriate, I wrote a > proposal: > > > https://wiki.openstreetmap.org/wiki/Proposed_features/notary > > > Definition: Notary services offered by a lawyers office I’m not an expert in the field, but from some reading it seems notaries public aren’t lawyers (in common law systems) and should be distinguished from civil law notaries? Can someone with more expertise confirm or dismiss? The wiki about the lawyer key isn’t helpful in defining the actual meaning of the tag: https://wiki.openstreetmap.org/wiki/Key:lawyer And this page suggests that the office=notary tag could be seen as equivalent: https://wiki.openstreetmap.org/wiki/Tag:office%3Dnotary Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Use of a site relation for grouping parking spaces
Thank to everybody, the text has been changed (by Mateusz Konieczny) accordingly: https://wiki.openstreetmap.org/w/index.php?title=Tag:amenity%3Dparking_space&diff=1928515&oldid=1890083 Ale On 03/12/19 23:42, Martin Koppenhoefer wrote: sent from a phone On 3. Dec 2019, at 20:32, Joseph Eisenberg wrote: I doubt it is useful to use a type=site relation with parking_space features at all. But your proposed rewording would be an improvement. I mostly agree, although one could construct situations where you might want to relate e.g. parking ticket machines or surveillance cameras (located outside the parking and represented by nodes) to specific parkings. Generally it doesn’t seem helpful to require a site relation, in most cases it wouldn’t add anything. Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Use of a site relation for grouping parking spaces
sent from a phone > On 3. Dec 2019, at 20:32, Joseph Eisenberg wrote: > > I doubt it is useful to use a type=site relation with parking_space features > at all. But your proposed rewording would be an improvement. I mostly agree, although one could construct situations where you might want to relate e.g. parking ticket machines or surveillance cameras (located outside the parking and represented by nodes) to specific parkings. Generally it doesn’t seem helpful to require a site relation, in most cases it wouldn’t add anything. Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Use of a site relation for grouping parking spaces
On 04/12/19 05:59, Alessandro Sarretta wrote: Dear tagging list, Should we maybe rephrase the sentence "Parking spaces *always have to* be grouped together in a site relation tagged with type=site + site=parking." in something like "Parking spaces *can* be grouped together in a site relation tagged with type=site + site=parking."? +1 .. Do it. If someone complains let 'us' know. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - Voting result - Pedestrian lane
Dear all, The voting on the proposal for a new key pedestrian_lane=* for lanes designated for pedestrians is over. 8 people voted for the proposal, 5 against it and 1 person abstained. This is an approval by 62%, which is below the required 75% majority. Therefore the proposal has been rejected. https://wiki.openstreetmap.org/wiki/Proposed_features/Pedestrian_lane The following reasons for opposing the proposal were given: - footway[:left/right]=lane should be used instead of the proposed pedestrian_lane=left/right/both. (mentioned twice) - More discussion is needed. (mentioned twice) - Disagreement with the definition of sidewalk=* being a raised or otherwise physically separated footpath at the side of a road. (mentioned once) In my opinion, footway[:left/right]=lane isn't a good idea for the following reasons: 1. footway=lane is a contradiction, as a lane (part of a road/path) isn't a footway (separate path). 2. sidewalk=left/right/both and footway[:left/right]=lane would have two different syntaxes, which were confusing. 3. lane would be the only value which were a departure from the usual tag syntax where the value is variable and the key remains constant. Many thanks to the (unfortunately rather few) people who took part in the vote. Best regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal – RFC – notary
Hi, I often found offices of lawyers, which are notaries, too, and office sharings of lawyers and notaries. To tag this appropriate, I wrote a proposal: https://wiki.openstreetmap.org/wiki/Proposed_features/notary Definition: Notary services offered by a lawyers office Regards Sebastian ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Use of a site relation for grouping parking spaces
On 03/12/2019 18:59, Alessandro Sarretta wrote: Should we maybe rephrase the sentence "Parking spaces *always have to* be grouped together in a site relation tagged with type=site + site=parking." in something like "Parking spaces *can* be grouped together in a site relation tagged with type=site + site=parking."? The last time this came up on this list I asked anyone if they could come up with anyone who manages to use site relation data for anything. I don't believe that anyone was able to suggest anything. I've certainly tried and failed to do something useful with site relations (for rendering). Your suggestion sounds like an improvement to me. Best Regards, Andy ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Use of a site relation for grouping parking spaces
I doubt it is useful to use a type=site relation with parking_space features at all. But your proposed rewording would be an improvement. Joseph On Tue, Dec 3, 2019 at 11:00 AM Alessandro Sarretta < alessandro.sarre...@gmail.com> wrote: > Dear tagging list, > > looking on how to use the tag amenity=parking_space ( > https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space) I've > always found the requirement that "parking spaces always have to be grouped > together in a site relation tagged with type=site + site=parking" too > complex and not really required by a general use case. > > I can think about areas with maybe 10 amenity=parking_spaces and a > surrounding amenity=parking, where I don't see any strong need to specify a > relation to group the parking spaces together. Here an example: > https://www.openstreetmap.org/way/658526498 > > Searching for a reason for this requirement, I haven't found here ( > https://wiki.openstreetmap.org/w/index.php?oldid=629318) a specific one. > > Looking here (https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site), > the reason to use the relation seems to be quite lighter: "Parking sites - > useful for cases where parking entrances are mapped but parking area is not > yet mapped. Once parking is mapped as an area with service roads marked > site relation is no longer useful and may be safely deleted." > > Should we maybe rephrase the sentence "Parking spaces *always have to* be > grouped together in a site relation tagged with type=site + site=parking." > in something like "Parking spaces *can* be grouped together in a site > relation tagged with type=site + site=parking."? > > Thank you for any comment, > > Ale > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Use of a site relation for grouping parking spaces
Dear tagging list, looking on how to use the tag amenity=parking_space (https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space) I've always found the requirement that "parking spaces always have to be grouped together in a site relation tagged with type=site + site=parking" too complex and not really required by a general use case. I can think about areas with maybe 10 amenity=parking_spaces and a surrounding amenity=parking, where I don't see any strong need to specify a relation to group the parking spaces together. Here an example: https://www.openstreetmap.org/way/658526498 Searching for a reason for this requirement, I haven't found here (https://wiki.openstreetmap.org/w/index.php?oldid=629318) a specific one. Looking here (https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site), the reason to use the relation seems to be quite lighter: "Parking sites - useful for cases where parking entrances are mapped but parking area is not yet mapped. Once parking is mapped as an area with service roads marked site relation is no longer useful and may be safely deleted." Should we maybe rephrase the sentence "Parking spaces *always have to* be grouped together in a site relation tagged with type=site + site=parking." in something like "Parking spaces *can* be grouped together in a site relation tagged with type=site + site=parking."? Thank you for any comment, Ale ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
