Re: [Tagging] Feature Proposal - RFC - parking=street_side
In this case you can simply use "parking:lane:right = parallel". Since it is a simple parking lane, it has nothing to do with street_side as suggested in the proposal. (The question is rather how to tag the bike lane - a suggestion is for example is https://wiki.openstreetmap.org/wiki/Proposed_features/cycleway:protection) Am 27.10.20 um 05:09 schrieb Phake Nick: > See "Parking-Protected Bike Lanes | The City of Portland, Oregon": > https://www.portlandoregon.gov/transportation/77882 > > 在 2020年10月27日週二 01:45，Supaplex 寫道： > >> Do you have an example picture/mapillary or similar of such a street? You >> call this case yourself "parking lane" and the way you describe it, it >> sounds like a typical case for parking:lane:* = >> parallel/diagonal/perpendicular, but not for >> parking:lane:*/parking=street_side. "street_side" is intended for cases >> where the parking spaces are structurally (especially structured by curbs) >> located on one side of the carriageway. (That means, if - hypothetically - >> no vehicles were parked there, you could still not drive there because curb >> extensions or street furniture would block a continuous drive.) >> >> A cycleway located behind this parking area is no longer part of the >> roadway and would therefore not be "lane" but "track". But maybe I >> misinterpreted the case you meant? >> >> >> Am 26.10.20 um 15:49 schrieb Paul Johnson: >> >> On Sat, Oct 24, 2020 at 6:40 AM Supaplex >> wrote: >> >> >> Hey all, >> >> I would like to invite you to discuss a proposal for "parking = >> street_side" for areas suitable or designated for parking, which are >> directly adjacent to the carriageway of a road and can be reached directly >> from the roadway without having to use an access >> way:https://wiki.openstreetmap.org/wiki/Proposed_features/parking%3Dstreet_side >> >> The proposed tagging can be used on separate parking areas as well as with >> the parking:lane-scheme. It aims not only to differentiate such >> street-accompanying parking areas from others, especially >> "parking=surface", but also addresses a contradiction in the current use of >> the amenity=parking and parking:lane-scheme, which I would like to mention >> briefly at this point: the use of "layby"/"lay_by". >> >> The value "layby" was originally intended for forms of resting places, as >> they seem to be especially common in rural areas of Great Britain, Ireland >> or the US: short-stop rest-areas along through-traffic roads intended for >> breaks during a car-trip (see Wikipedia for a >> definition:https://en.wikipedia.org/wiki/Rest_area#Lay-bys). On areas with >> "amenity=parking" this key is also used in this sense (and mostly in Great >> Britain). >> >> Within the parking:lane-schema, however, the value "lay_by" (written with >> an underscore) has gained acceptance. According to the Wiki, this value is >> defined identically to the layby's mentioned above. Its actual use, >> however, differs from this and includes mainly street-side parking, as we >> address them in our proposal. >> >> >> How does this work out when the parking lane is not the curb lane? This >> arrangement is increasingly common in North America, where the parking >> isn't at the side of the road, one or more bicycle lanes are. >> >> >> >> ___ >> Tagging mailing >> listTagging@openstreetmap.orghttps://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 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
On 27-10-2020 09:30, Martin Koppenhoefer wrote: > because in OpenStreetMap everything is “valid”, but both approaches > are not equally good. In this specific case, as soon as > landuse=highway is mapped as an area, having connected the adjacent > landuses to the middle of the street will become utterly wrong and > will have to be fixed, up to then, it just means generalizing at the > expense of having everything on the road and sidewalks misrepresented > as lying on the neighbouring areas. Perhaps I could have better phrased that by stating that both approaches are in common use, and from the perspective of our proposal both approaches should work. Personally, I agree. In the example graphics we do focus on the separately drawn method where the explicitly mapped method is discussed. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
sent from a phone > On 27. Oct 2020, at 08:17, Jeroen Hoek wrote: > > Both approaches are valid because in OpenStreetMap everything is “valid”, but both approaches are not equally good. In this specific case, as soon as landuse=highway is mapped as an area, having connected the adjacent landuses to the middle of the street will become utterly wrong and will have to be fixed, up to then, it just means generalizing at the expense of having everything on the road and sidewalks misrepresented as lying on the neighbouring areas. Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
On 26-10-2020 21:24, Matthew Woehlke wrote: > If parking is on both sides of the street, the parking area already > crosses the street, and even if it doesn't, logically the parking area > *does* connect to the street. I disagree with the argument that mapping > thus is somehow "wrong", and indeed, I usually map parking that way. I'm afraid there is no consensus on how to map features along a street exactly. Similar to how some mappers glue landuse=relational (etc.) to the street and some use the boundary of the combined plots of the block. Both approaches are valid; the latter is more suitable where highly accurate boundary data is freely available along with high resolution satellite imagery (e.g., the Netherlands) and mappers. Personally, extending the parking area over the carriage way feels like mapping for the router, in that I would be drawing a parking area where there is none just to reach the highway-line in the middle of the street. You are right about mapping the spaces of course; I do so when possible. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
See "Parking-Protected Bike Lanes | The City of Portland, Oregon": https://www.portlandoregon.gov/transportation/77882 在 2020年10月27日週二 01:45，Supaplex 寫道： > Do you have an example picture/mapillary or similar of such a street? You > call this case yourself "parking lane" and the way you describe it, it > sounds like a typical case for parking:lane:* = > parallel/diagonal/perpendicular, but not for > parking:lane:*/parking=street_side. "street_side" is intended for cases > where the parking spaces are structurally (especially structured by curbs) > located on one side of the carriageway. (That means, if - hypothetically - > no vehicles were parked there, you could still not drive there because curb > extensions or street furniture would block a continuous drive.) > > A cycleway located behind this parking area is no longer part of the > roadway and would therefore not be "lane" but "track". But maybe I > misinterpreted the case you meant? > > > Am 26.10.20 um 15:49 schrieb Paul Johnson: > > On Sat, Oct 24, 2020 at 6:40 AM Supaplex > wrote: > > > Hey all, > > I would like to invite you to discuss a proposal for "parking = > street_side" for areas suitable or designated for parking, which are > directly adjacent to the carriageway of a road and can be reached directly > from the roadway without having to use an access > way:https://wiki.openstreetmap.org/wiki/Proposed_features/parking%3Dstreet_side > > The proposed tagging can be used on separate parking areas as well as with > the parking:lane-scheme. It aims not only to differentiate such > street-accompanying parking areas from others, especially > "parking=surface", but also addresses a contradiction in the current use of > the amenity=parking and parking:lane-scheme, which I would like to mention > briefly at this point: the use of "layby"/"lay_by". > > The value "layby" was originally intended for forms of resting places, as > they seem to be especially common in rural areas of Great Britain, Ireland > or the US: short-stop rest-areas along through-traffic roads intended for > breaks during a car-trip (see Wikipedia for a > definition:https://en.wikipedia.org/wiki/Rest_area#Lay-bys). On areas with > "amenity=parking" this key is also used in this sense (and mostly in Great > Britain). > > Within the parking:lane-schema, however, the value "lay_by" (written with > an underscore) has gained acceptance. According to the Wiki, this value is > defined identically to the layby's mentioned above. Its actual use, > however, differs from this and includes mainly street-side parking, as we > address them in our proposal. > > > How does this work out when the parking lane is not the curb lane? This > arrangement is increasingly common in North America, where the parking > isn't at the side of the road, one or more bicycle lanes are. > > > > ___ > Tagging mailing > listTagging@openstreetmap.orghttps://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] Feature Proposal - RFC - parking=street_side
On 26/10/2020 15.19, Jeroen Hoek wrote: On 26-10-2020 19:31, Matthew Woehlke wrote: Alternatively, clients might look at the sort of highway running through a parking area. A highway=tertiary is probably "street-side parking", while a highway=service, service=parking_aisle probably is not. That's not a bad thought, but it would require connecting the street-side parking area to the highway (e.g., by extending the area to the middle of the carriage way), which goes against the principle of mapping what is there. If parking is on both sides of the street, the parking area already crosses the street, and even if it doesn't, logically the parking area *does* connect to the street. I disagree with the argument that mapping thus is somehow "wrong", and indeed, I usually map parking that way. The problem with the parking area potentially being misleading (which anyway is an issue of the consumer not considering how the adjacent highway infringes on the parking area) can be solved by also mapping the spaces. I don't think renderers tend to have this information available in any case. Perhaps, but at that point we're tagging for the renderer. I was thinking of other clients (e.g. routers). -- Matthew ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
On 26-10-2020 19:31, Matthew Woehlke wrote: > Alternatively, clients might look at the sort of highway running > through a parking area. A highway=tertiary is probably "street-side > parking", while a highway=service, service=parking_aisle probably is > not. That's not a bad thought, but it would require connecting the street-side parking area to the highway (e.g., by extending the area to the middle of the carriage way), which goes against the principle of mapping what is there. I don't think renderers tend to have this information available in any case. Another notion I had was that renderers could just use capacity=* as a measure of how visible a parking amenity should be, but that would require knowing the capacity, which is not always plausible (and it could lure mappers into tagging a capacity value they deem suitable for rendering reasons). Of course, using capacity=* as well as parking=* can be useful to highlight huge parking facilities at an earlier zoom-level (I think Carto uses only the area size at the moment to do this). All in all simply adding this sub-tag value seems the clearer option. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
On 25/10/2020 03.58, Jeroen Hoek wrote: Our proposal facilitates this: renderers can render street-side parking however they wish, because the tag tells them it is street-side parking. Alternatively, clients might look at the sort of highway running through a parking area. A highway=tertiary is probably "street-side parking", while a highway=service, service=parking_aisle probably is not. That said, I'm not adamantly opposed to the proposal, having encountered situations myself where such a tag would have made how to map this sort of thing much more obvious. -- Matthew ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
Do you have an example picture/mapillary or similar of such a street? You call this case yourself "parking lane" and the way you describe it, it sounds like a typical case for parking:lane:* = parallel/diagonal/perpendicular, but not for parking:lane:*/parking=street_side. "street_side" is intended for cases where the parking spaces are structurally (especially structured by curbs) located on one side of the carriageway. (That means, if - hypothetically - no vehicles were parked there, you could still not drive there because curb extensions or street furniture would block a continuous drive.) A cycleway located behind this parking area is no longer part of the roadway and would therefore not be "lane" but "track". But maybe I misinterpreted the case you meant? Am 26.10.20 um 15:49 schrieb Paul Johnson: > On Sat, Oct 24, 2020 at 6:40 AM Supaplex wrote: > >> Hey all, >> >> I would like to invite you to discuss a proposal for "parking = >> street_side" for areas suitable or designated for parking, which are >> directly adjacent to the carriageway of a road and can be reached directly >> from the roadway without having to use an access way: >> https://wiki.openstreetmap.org/wiki/Proposed_features/parking%3Dstreet_side >> >> The proposed tagging can be used on separate parking areas as well as with >> the parking:lane-scheme. It aims not only to differentiate such >> street-accompanying parking areas from others, especially >> "parking=surface", but also addresses a contradiction in the current use of >> the amenity=parking and parking:lane-scheme, which I would like to mention >> briefly at this point: the use of "layby"/"lay_by". >> >> The value "layby" was originally intended for forms of resting places, as >> they seem to be especially common in rural areas of Great Britain, Ireland >> or the US: short-stop rest-areas along through-traffic roads intended for >> breaks during a car-trip (see Wikipedia for a definition: >> https://en.wikipedia.org/wiki/Rest_area#Lay-bys). On areas with >> "amenity=parking" this key is also used in this sense (and mostly in Great >> Britain). >> >> Within the parking:lane-schema, however, the value "lay_by" (written with >> an underscore) has gained acceptance. According to the Wiki, this value is >> defined identically to the layby's mentioned above. Its actual use, >> however, differs from this and includes mainly street-side parking, as we >> address them in our proposal. >> > How does this work out when the parking lane is not the curb lane? This > arrangement is increasingly common in North America, where the parking > isn't at the side of the road, one or more bicycle lanes are. > > > ___ > 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 - parking=street_side
On Sat, Oct 24, 2020 at 6:40 AM Supaplex wrote: > Hey all, > > I would like to invite you to discuss a proposal for "parking = > street_side" for areas suitable or designated for parking, which are > directly adjacent to the carriageway of a road and can be reached directly > from the roadway without having to use an access way: > https://wiki.openstreetmap.org/wiki/Proposed_features/parking%3Dstreet_side > > The proposed tagging can be used on separate parking areas as well as with > the parking:lane-scheme. It aims not only to differentiate such > street-accompanying parking areas from others, especially > "parking=surface", but also addresses a contradiction in the current use of > the amenity=parking and parking:lane-scheme, which I would like to mention > briefly at this point: the use of "layby"/"lay_by". > > The value "layby" was originally intended for forms of resting places, as > they seem to be especially common in rural areas of Great Britain, Ireland > or the US: short-stop rest-areas along through-traffic roads intended for > breaks during a car-trip (see Wikipedia for a definition: > https://en.wikipedia.org/wiki/Rest_area#Lay-bys). On areas with > "amenity=parking" this key is also used in this sense (and mostly in Great > Britain). > > Within the parking:lane-schema, however, the value "lay_by" (written with > an underscore) has gained acceptance. According to the Wiki, this value is > defined identically to the layby's mentioned above. Its actual use, > however, differs from this and includes mainly street-side parking, as we > address them in our proposal. > How does this work out when the parking lane is not the curb lane? This arrangement is increasingly common in North America, where the parking isn't at the side of the road, one or more bicycle lanes are. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
On 2020-10-25 15:47, Allroads wrote: > All landuse what is used for legally public roads, laid down in a zoning plan > by the Government "bestemmingsplan" should be called landuse=highway no, > because the content of a bestemmingsplan is what is politically desired and > legally permitted, it is a plan. Landuse is not about the zoning plan, it is > about the actual current landuse, regardless of its compatibility with the > legal situation. That's the irrevocable plan, then all is shaped. There can be a considerable amount of time between the approval of a "bestemmingsplan" and its actual implementation in the case of certain properties. When a plan is changed (a political decision) this gives rise to claims for damages, and official waivers for the current status (that may only apply to the current residents for example). There are lots of ways in which the reality can legally diverge from the "bestemmingsplan". As OSM prefers the reality to the theory, a zoning plan can only be an indication. It will however often be in line with reality.___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
All landuse what is used for legally public roads, laid down in a zoning plan by the Government "bestemmingsplan" should be called landuse=highway no, because the content of a bestemmingsplan is what is politically desired and legally permitted, it is a plan. Landuse is not about the zoning plan, it is about the actual current landuse, regardless of its compatibility with the legal situation. That's the irrevocable plan, then all is shaped. For Netherlands law https://wetten.overheid.nl/BWBR0006622/2020-10-01 describing what belongs to a road. " wegen: alle voor het openbaar verkeer openstaande wegen of paden met inbegrip van de daarin liggende bruggen en duikers en de tot die wegen behorende paden en bermen of zijkanten; " " roads: all roads or paths open to public traffic, including bridges and culverts situated therein and the paths and verges or sides belonging to those roads; " All landuse=highway. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
sent from a phone > On 25. Oct 2020, at 14:41, Allroads wrote: > > All landuse what is used for legally public roads, laid down in a zoning plan > by the Government "bestemmingsplan" should be called landuse=highway no, because the content of a bestemmingsplan is what is politically desired and legally permitted, it is a plan. Landuse is not about the zoning plan, it is about the actual current landuse, regardless of its compatibility with the legal situation. Cheers Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
For me, the value "parking_space" what key, single space problem must be fixed first to say something about "street_side". As it comes to a vote. Could you elaborate? amenity=parking_space can be used as usual within amenity=parking. This of course also works with amenity=parking/parking=street_side: https://www.openstreetmap.org/way/849745989 Our proposal doesn't affect the documented use of amenity=parking_space; you would use it just the same as with parking=surface. Reading parts over the years about parking. A lot of people do no see amenity=parking as a good tag for street side parking. Mainly prompted by wiki (image) en carto, the visualisation of P. https://wiki.openstreetmap.org/wiki/Parking street side parking is the only method in given on this page. The main tag covering most conventional car parks, coach parks etc. Many additional tags are listed on this page. We will always have that opposition. Also a question for me, must we split the tagging there, when we still can. amenity is mostly with a sign https://wiki.openstreetmap.org/w/images/thumb/8/80/NLE04.gif/60px-NLE04.gif amenity=parking_space can only be tagged on a amenity=parking? https://www.openstreetmap.org/relation/11650954#map=19/53.21448/5.80418 Why is this a relation and not only polygon tagging. (That is a other discussion, but rubs against it) If some, we, not use amenity=parking, how to tag the parking_space as a value? There spots, where people park in the verge, on the grass, or other surface grass_paver, what is permitted. In or outside the residential area. ( "bebouwde kom") https://wiki.openstreetmap.org/w/images/thumb/b/bc/NLE01.gif/60px-NLE01.gif have not a effect on the verge, the EU rule is no_parking on the carriageway. The operating force of a traffic sign may not be expanded. https://upload.wikimedia.org/wikipedia/commons/thumb/8/8b/Nederlands_verkeersbord_B1.svg/60px-Nederlands_verkeersbord_B1.svg.png. Outside the residential area "bebouwde kom" it is prohibited to park on the carriageway, but not on the verge. How do we do that with parking, amenity=parking? Also the structure of the area:highway methodology, which needs to be further developed in detail. All landuse what is used for legally public roads, laid down in a zoning plan by the Government "bestemmingsplan" should be called landuse=highway, inside this polygon the objects are area:highway https://wiki.openstreetmap.org/wiki/Proposed_features/area:highway https://wiki.openstreetmap.org/wiki/Proposed_features/area_highway/mapping_guidelines There is area:highway=traffic_island https://overpass-turbo.eu/s/Znt there should be area:highway=verge, the busbay is also not well documented. https://wiki.openstreetmap.org/wiki/Key:shoulder the polygon equivalent is area:highway=shoulder. https://wiki.openstreetmap.org/wiki/Key:verge the polygon equivalent is area:highway=verge (verge:access:motorcar=no when parking on the verge is expressly prohibited.) But there is this used area:highway=parking_space, and not for only one space. What a space should be. https://wiki.openstreetmap.org/w/images/4/42/MarekXjunctionExampleWithTagging.jpg area:highway is a used key. All these parking area, should get a tag area:highway, but which? Or both amenity=parking. Or is amenity parking only for lots. https://overpass-turbo.eu/s/Zns ["area:highway"="parking_space"] or is it area:highway=service service=parking_space if it is one space, with multiple not drawn in space, service=parking. That is why I wrote. For me, The search for good cohesion. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
On 24-10-2020 22:27, Allroads wrote:> Use area:highway for polygon and parking! I will clarify the relation of our proposal to area:highway, thanks for pointing it out. In brief, the two tagging methods coexist and complement each other. Our proposal focuses on the parking-amenity (and thus amenity=parking) aspect of these street-side parking areas. Anyone mapping with area:highway can of course use amenity=parking|parking=street_side, and either: * include the parking areas within a area:highway=residential or similar; * use area:highway=service; * or not include them within the highway area and leave them as-is. What the right approach is, is probably beyond the scope of our proposal, and should be discussed within the scope of the area:highway proposals instead. I think it suffices to say that amenity=parking|parking=street_side complements area:highway mapping if applied, but doesn't require it. > For me, the value "parking_space" what key, single space problem must > be fixed first to say something about "street_side". As it comes to a vote. Could you elaborate? amenity=parking_space can be used as usual within amenity=parking. This of course also works with amenity=parking/parking=street_side: https://www.openstreetmap.org/way/849745989 Our proposal doesn't affect the documented use of amenity=parking_space; you would use it just the same as with parking=surface. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
On 24-10-2020 23:54, Paul Allen wrote: > So tagging for the renderer because, in your opinion, these car parking > areas are unimportant. By that line of reasoning tagging highways anything other than highway=motorway is tagging for the renderer. I understand your concern, but no, it is not our opinion that these car parking areas are unimportant (we wouldn't map them if we thought so). This proposal is not about declaring one type of parking more important than the other. It does standardise a new parking=* and parking:lane=* value for a distinct, commonly mapped, and ubiquitous type of parking area. Because of the way these features are present on the ground, it makes sense for a renderer to consider a different rendering approach than they would for a parking garage of parking lot. And yes, for a general purpose map, that may involve de-emphasizing them. In the Netherlands we've had a case where a misguided mapper imported this type of street-side parking area in one city (the import was not properly discussed and documented and has since been reverted). They used amentity=parking_space on those areas instead of amenity=parking (even though most contained at least two parking spaces), because they didn't like the way amenity=parking rendered on Carto with hundreds of parking areas mapped. That is tagging for the renderer. We want to prevent that. By introducing a relevant sub-tag value renderers and routers may act on, we prevent tagging for the renderer, and encourage the use of a semantically correct tag-value. A collatoral effect is that the existing parking=* values will become less abused (e.g., surface and layby) for street-side parking. Mappers who want to map street-side parking, can do so knowing that any rendering issues can be dealt with by any renderer on the base of the correct sub-tag value. Whether renderers will act on this or not is of course a stylistic choice not part of this proposal, but we do offer some suggestions (under 'Rendering'). Of course, I can fully imagine some types of map or overlay that actively highlight street-side parking! For example some sort of 'parking-mode' on a router's screen when you are nearing your destination. Similarly, some users may prefer street-side parking over parking garages (camper/RV owners perhaps), and instruct their router to filter on those. Our proposal facilitates this: renderers can render street-side parking however they wish, because the tag tells them it is street-side parking. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
On Sat, 24 Oct 2020 at 15:51, Jeroen Hoek wrote: > On 24-10-2020 15:58, Paul Allen wrote: > > I don't see any valid reason for wanting to de-emphasize them and you > > do not attempt to provide one. Maybe there is a valid reason but I > > don't see it. > > Thanks for the feedback; we'll clarify that point. From the proposal: > > > Furthermore, this type of parking may have different rendering and > > navigation needs compared to other types of parking (see below). > This is mainly about preventing the visual clutter of blue P's that are > the result of tagging amenity=parking without any parking sub-tag or an > unsuitable one. Ah, so you want to tag for the renderer. Firstly, the renderer could choose not to show small car parks below a certain zoom level, which would prevent clutter automatically and is preferable to mappers tagging "In MY opinion, this car park is unimportant." Street-side parking usually isn't of interest until you > are in the area or are orienting yourself for a trip to visit a POI > nearby. If you're not in the area but expect to go there and are looking for parking, ALL parking areas are of potential interest. > Unlike dedicated parking facilities (like a parking lot or > parking garage), the scale of these is much smaller, yet they are also > much more ubiquitous. > And people park in them. Which kind of defeats any argument that they are of lesser importance. Often they are free, although of limited duration, which can make them preferable. Often they are nearer to a POI or group of POIs than the larger car parks. Often such parking areas are full when large car parks are not. > > Parking=street_side allows for renderers to de-emphasize these areas > (for a few suggestions, please see the proposal under 'Rendering'), > without sacrificing the findability of dedicated parking lots/garages > (especially if these lack capacity information). > So tagging for the renderer because, in your opinion, these car parking areas are unimportant. -- Paul ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
On Sat, 24 Oct 2020 at 15:25, Janko Mihelić wrote: > > These two variants are mapping for the renderer, > Incorrect. They are approximations to reality. Everything we map is an approximation to reality, one way or another, because the map is a representation. That they happen to render in a way that is a closer representation to what is there is a bonus. > and both add false data. > The first one can be interpreted that way. The second cannot. > The first one extends the parking over half the road. > Yes. That's what the data purist objected to. But for the average human data consumer, that is not apparent. You may object to it somehow being tagging for the renderer (it isn't) but it is relying on one error in representation hiding a different error in representation. The renderer doesn't show the true width of the carriageway - if it did then mapping the actual extent of the parking area would result in it abutting the carriageway. However, a different error in representation results in the carriageway being rendered over the parking area. The result that is rendered better represents reality on the ground and what an ordinary user expects to see. But you seem to object to maps that match what a human user would expect to see. > The second creates a service road area over half the road. There is no > service road area there, > Yes there is. It's a very wide, very short service road connecting the carriageway to the parking area. You're trying to pretend it isn't there and that there is a void between the two. > you are just trying to connect the parking to the road so it looks nice on > the map. And it does look nice, but it's false data. > It is absolutely true data. It is the same surface as the carriageway and the parking area with only lane markings to delineate it. It looks rather ugly, not nice. But it is absolutely true. Are you saying there is no way to drive from the carriageway to the parking area? If not, there is something connecting the two. That connection is a very wide, very short service road. It is you who is insisting on false data by pretending there is no road surface between carriageway and parking area. If we want to describe how you get onto street side parking, and it's not > obvious, we could use additional tags, like parking_entrance_direction=*. > Let's tag everything so that NOTHING renders and the user has to use the query tool to find out what is there. Apart from the fact that no human map user is going to see any clue about the parking entrance direction, now will the human user know that the entrance extends the whole length of the parking area. > Street side parking is a very different parking area from a big enclosed > surface parking. Some people may find it hard to park there because you > back up onto traffic, > The two examples I gave have the parking parallel with the carriageway, so there is no backing up involved. > and they may want to avoid parking there. This information is definitely > very useful. > If that information is very useful, why are you proposing tagging it in a way that is not only not rendered but doesn't give any clue about it if you use the query tool? -- Paul ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
The two methods: 1. Tagging on the way line. When a road, highway=* 2. Tagging a polygon. When a road, area:highway=* Will always be used next to each other. We have to take that into account. New mappers, see a parking plot/space and want to draw that in, that is logical behaviour. It is obvious for them to draw a polygon. And want them to see on a map. It is not obvious for them to tag parking:lane on a highway=*, the method for wayline parking. Originated with the first development of Openstreetmap, then the system evolved, area:highway was developed later. We must give them the opportunity to do so, polygon mapping. Topographical mapping. Also for on the lane parking, we need the polygon to draw in, because space lines are painted on the road or different paving, indicating parking spaces, parking traffic signs refer to it. In the mind of general people there is no difference on the carriageway or beside, for them it is both street side parking. street_side is also on the lane parking. It is more a general term. (I think, maybe more for not native UK people). Do not make a difference between carriageway (painted, surfaced) and beside parking by choosing street_side value as a tag for one (beside). Polygon: Where the transportation modes can walk/ride/drive on a polygon, we tag area:highway=* , that is a base tag. On a way, highway=* we have residential and service and service=parking_aisle, this is on a amenity=parking. For a polygon on lane and beside we have area:highway=service, even when you draw in a amenity parking, you have area:highway, there the lane is area:highway=service service=parking_aisle, parking spaces are a kind of service. The plot/space on a amenity=parking, https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space , there is no much visual difference, when there is a parking_space on a amenity and or on the (marked parking) carriageway or beside parking. The value should/could also be used. There everywhere, places for disabled parking and electric parkin a spaces On the lane road with no marking, there is only the (1.) wayline tagging, parking:lane possible, A carriageway, can have, wayline tagging highway=residential with parking:lane=no_parking, polygon highway tagging area:highway=residential, the lane to walk/ride/drive polygon parking tagging area:highway=service service=parking parking=street_side on lane and beside parking:condition=free In this example there is a no_parking traffic_sign on both side of the road, EU rules, determine that such traffic_sign, no_parking only prohibited parking on the lane, and not the marked parking spaces or the verge. So w must have the opportunity to tag it properly, this is a example both methods of tagging are needed (line polygon). Use area:highway for polygon and parking! The combination area:highway=service and service=parking, should be enough indication for the render to not set a P. (Carto) Even when there is a amenity=parking is set. (wrongly?) parking= street_side could be used there is no conflict parking=* on amenity with parking https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking#Additional_Tags The only point for me is, can also the value "parking_space" be used, with what key? area:highway=service service=parking parking=parking_space(?) (Do we need street_side?) Or is it parking:street_side=parallel People, want to draw in a single space. We have to take that into account. But others draw in several spaces as a one object, parking_space, this is not correct. It must be clear that there is a single spot. Somewhere the value "parking_space" must fit in. parking_space=disabled, this must not be different then on a amenity=parking, if, that is confusing for a lot of people ( taggers), now with electric cars there lots op spaces where only they can park, traffic_sign prohibition next to the space, single space are more drawn in the future. Prohibited access on the space. Netherlands Government, are going to draw in all these spaces, each space get a ref, for linked data, the cost of electric charging, and more. Amenity parking and carriageway parking, space tagging must be with the same tags. If they look the same and the use is the same. So, we must prepared for more detailed mapping. This kind of tagging is almost impossible on a wayline, all these way cuts, visualisation and control the data. A polygon visualisation is more clear. For me, the value "parking_space" what key, single space problem must be fixed first to say something about "street_side". As it comes to a vote. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
On 24-10-2020 16:22, Janko Mihelić wrote: > These two variants are mapping for the renderer, and both add false > data. The first one extends the parking over half the road. The second > creates a service road area over half the road. There is no service road > area there, you are just trying to connect the parking to the road so it > looks nice on the map. And it does look nice, but it's false data. Agreed. There may be a handful of cases where a router won't route you to a spot on the road right next to an explicitly mapped parking=street_side area mapped the way shown in our proposal, but I don't think that is a very common use case; you normally wouldn't target a specific street-side parking area. If I want to visit a friend or a small shop in an area without dedicated parking lost/garages, I would look around on the map to orient myself, and probably set the destination to the address I am going, or somewhere along a road from whereon I would go look for a free spot using the map to show me streets where I can park. With a large parking garage you definitely would select that as the destination if you are using a router, but that is a different kind of beast. > Street side parking is a very different parking area from a big enclosed > surface parking. Some people may find it hard to park there because you > back up onto traffic, and they may want to avoid parking there. This > information is definitely very useful. Exactly. Our proposal should benefit other types of amenity=parking such as parking=surface (etc.) by giving routers and renderers a way to ignore and de-emphasize, respectively, street-side parking. It also benefits data consumers (including routers) when asking for a list of parking facilities nearby: street-side parking can be properly classified and described as such, and potentially shown lower in the list below any public parking lots/garages. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
On 24-10-2020 15:58, Paul Allen wrote: > I don't see any valid reason for wanting to de-emphasize them and you > do not attempt to provide one. Maybe there is a valid reason but I > don't see it. Thanks for the feedback; we'll clarify that point. From the proposal: > Furthermore, this type of parking may have different rendering and > navigation needs compared to other types of parking (see below). This is mainly about preventing the visual clutter of blue P's that are the result of tagging amenity=parking without any parking sub-tag or an unsuitable one. Street-side parking usually isn't of interest until you are in the area or are orienting yourself for a trip to visit a POI nearby. Unlike dedicated parking facilities (like a parking lot or parking garage), the scale of these is much smaller, yet they are also much more ubiquitous. Parking=street_side allows for renderers to de-emphasize these areas (for a few suggestions, please see the proposal under 'Rendering'), without sacrificing the findability of dedicated parking lots/garages (especially if these lack capacity information). ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
On 24-10-2020 15:58, Paul Allen wrote: > What you haven't convinced me of is that it isn't amenity=parking. > By any rational definition it is. I know of off-carriageway parking > which is controlled by a county council and has a ticket > machine. The county council lists it as a car park, one > of three car parks in the town, and makes no distinction. It is amenity=parking. The proposal proposes a new value parking=street_side. This is in addition to the parent tag amenity=parking. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
sub, 24. lis 2020. u 15:14 Paul Allen napisao je: > Variant 1. Extend the parking area out to the roat it is on. Pretty much > as > you handled the lay-by example. As far as rendering goes, where most > carto renders the road on top of the parking area, it represents things > as a way that matches reality. Here's one I did years ago. > > > https://www.openstreetmap.org/?mlat=52.08560=-4.65830#map=19/52.08560/-4.65830 > Streetview for comparison: https://goo.gl/maps/R7Q1RUWGziLaMemW8 > > A data purist on the list objected to that. The rendering is a good > representation of reality but if a data consumer were to look at the > data rather than the rendering then he or she would assume the > car could be parked perpendicular to the carriageway with half > the car blocking traffic. So for purists... > > Variant 2. Map the precise boundary of the parking area. Connect it > to the carriageway with highway=service + area=yes. This results > in rendering that is an even better (if slightly uglier) representation of > reality at the expense of extra effort. Here's one I did a few weeks > ago to test the idea. > > > https://www.openstreetmap.org/?mlat=52.08268=-4.66461#map=19/52.08268/-4.66461 > Streetview for comparison: https://goo.gl/maps/YHTv9dDvSbm6DL1A8 The > streetview is somewhat misleading as recent aerial imagery shows clear > surface marking delineating the boundaries. That's also a weird example > because some of it is off-carriageway and some on-carriageway (turn 180 > degrees in streetview and move forward to see), a situation your proposal > doesn't cater to. > These two variants are mapping for the renderer, and both add false data. The first one extends the parking over half the road. The second creates a service road area over half the road. There is no service road area there, you are just trying to connect the parking to the road so it looks nice on the map. And it does look nice, but it's false data. If we want to describe how you get onto street side parking, and it's not obvious, we could use additional tags, like parking_entrance_direction=*. Street side parking is a very different parking area from a big enclosed surface parking. Some people may find it hard to park there because you back up onto traffic, and they may want to avoid parking there. This information is definitely very useful. Janko ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
On Sat, 24 Oct 2020 at 14:35, Jeroen Hoek wrote: > On 24-10-2020 15:11, Paul Allen wrote: > > As rendered it appears you need a skyhook or > > a cargo helicopter to park. Not good. You're probably as unhappy with > that > > method of tagging as I am. > > True, but the same goes for lots of points-of-interests and other mapped > parts of the urban landscape; e.g., patches of grass, shrubs, benches, > bicycle parking areas, etc. In all these cases mapping the exact area > results in a neat map that makes sense for orientation as well as > finding parking spaces for motorists in the neighbourhood. > Car parking areas are, I feel, in a different category to benches. You walk to a bench and can infer that if a bench is present you can walk to it unless there are barriers. With car parking areas you need actual routes. There are off-carriageway parking areas where the entry might be from either of two parallel streets (or both) which is unclear if we adopt helicopter parking tagging. Fixing the helicopter tagging also fixes the ambiguities that seem to be the only justification for your proposal. > While being able to route exactly onto a point-of-interest is valuable > in some cases, for the use case of this proposal I would say that it is > not as relevant. In which case, I don't see any use case for your proposal at all. > Besides, if someone really wants to navigate to a > specific mapped street-side parking area, their router will tend to > route to the nearest point it can get too, which more often than not > will be right in front of the parking area. > And sometimes isn't. Two parallel roads. I've seen this case somewhere, but I can't remember where. Worse, the nearest point a router could get to is the road that doesn't have access to the parking. > > This proposal provides tag-values for a common type of parking area > already mapped in great quantities, and hard to ignore at a certain > level of detail. It gives mappers a way to map them without bending > existing tags (e.g., parking=surface, parking=layby), I agree, it's not a layby. Technically, cars do park at a layby but I don't think of a layby as being a car parking area or vice versa. It's certainly not parking=surface which applies (by default) to any car park that isn't either multi-storey or underground. What you haven't convinced me of is that it isn't amenity=parking. By any rational definition it is. I know of off-carriageway parking which is controlled by a county council and has a ticket machine. The county council lists it as a car park, one of three car parks in the town, and makes no distinction. and it eventually > gives renderers a way to de-emphasize them (the proposal has a few > suggestions) compared with the more 'high-value' parking facilities like > large capacity public parking=surface|multistory|underground. > I don't see any valid reason for wanting to de-emphasize them and you do not attempt to provide one. Maybe there is a valid reason but I don't see it. It's a place to park. Somebody looking for a place to park near to their objective will be just as interested in off-carriageway parking as an ordinary car park. If applied consistently, this proposal will increase the relevance of > parking areas that really are parking=surface|layby|etc. > You wish to increase the relevance by de-emphasising. I don't see how that works. Maybe we could increase the relevance even more by not mapping them at all - the ultimate in de-emphasis and therefore the ultimate in relevance. -- Paul ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
On 24-10-2020 15:11, Paul Allen wrote: > As rendered it appears you need a skyhook or > a cargo helicopter to park. Not good. You're probably as unhappy with that > method of tagging as I am. True, but the same goes for lots of points-of-interests and other mapped parts of the urban landscape; e.g., patches of grass, shrubs, benches, bicycle parking areas, etc. In all these cases mapping the exact area results in a neat map that makes sense for orientation as well as finding parking spaces for motorists in the neighbourhood. While being able to route exactly onto a point-of-interest is valuable in some cases, for the use case of this proposal I would say that it is not as relevant. Besides, if someone really wants to navigate to a specific mapped street-side parking area, their router will tend to route to the nearest point it can get too, which more often than not will be right in front of the parking area. This proposal provides tag-values for a common type of parking area already mapped in great quantities, and hard to ignore at a certain level of detail. It gives mappers a way to map them without bending existing tags (e.g., parking=surface, parking=layby), and it eventually gives renderers a way to de-emphasize them (the proposal has a few suggestions) compared with the more 'high-value' parking facilities like large capacity public parking=surface|multistory|underground. If applied consistently, this proposal will increase the relevance of parking areas that really are parking=surface|layby|etc. Kind regards, Jeroen Hoek Co-author of this proposal ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
On Sat, 24 Oct 2020 at 12:42, Supaplex wrote: I would like to invite you to discuss a proposal for "parking = > street_side" for areas suitable or designated for parking, which are > directly adjacent to the carriageway of a road and can be reached directly > from the roadway without having to use an access way: > https://wiki.openstreetmap.org/wiki/Proposed_features/parking%3Dstreet_side > I don't think a new parking=street_side is necessary for off-carriageway street-side parking. The example image you give in the sub-section "Tagging" https://wiki.openstreetmap.org/w/images/thumb/b/b8/Parking-render-carto.png/500px-Parking-render-carto.png is (in my opinion) not a good way to use existing tagging. The parking areas are not routeable (not a big problem unless somebody wants to route to a named parking area). As rendered it appears you need a skyhook or a cargo helicopter to park. Not good. You're probably as unhappy with that method of tagging as I am. Connecting it with an invented service road also misrepresents the true situation. But there is another way of doing it. A way which comes in two variants, either quick-and-dirty or purist. Variant 1. Extend the parking area out to the roat it is on. Pretty much as you handled the lay-by example. As far as rendering goes, where most carto renders the road on top of the parking area, it represents things as a way that matches reality. Here's one I did years ago. https://www.openstreetmap.org/?mlat=52.08560=-4.65830#map=19/52.08560/-4.65830 Streetview for comparison: https://goo.gl/maps/R7Q1RUWGziLaMemW8 A data purist on the list objected to that. The rendering is a good representation of reality but if a data consumer were to look at the data rather than the rendering then he or she would assume the car could be parked perpendicular to the carriageway with half the car blocking traffic. So for purists... Variant 2. Map the precise boundary of the parking area. Connect it to the carriageway with highway=service + area=yes. This results in rendering that is an even better (if slightly uglier) representation of reality at the expense of extra effort. Here's one I did a few weeks ago to test the idea. https://www.openstreetmap.org/?mlat=52.08268=-4.66461#map=19/52.08268/-4.66461 Streetview for comparison: https://goo.gl/maps/YHTv9dDvSbm6DL1A8 The streetview is somewhat misleading as recent aerial imagery shows clear surface marking delineating the boundaries. That's also a weird example because some of it is off-carriageway and some on-carriageway (turn 180 degrees in streetview and move forward to see), a situation your proposal doesn't cater to. I don't see your proposal achieving anything we can't already do and doesn't keep the data purists happy, either. -- Paul ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - parking=street_side
I support parking=street_side, this is a much needed tag. Janko ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - parking=street_side
Hey all, I would like to invite you to discuss a proposal for "parking = street_side" for areas suitable or designated for parking, which are directly adjacent to the carriageway of a road and can be reached directly from the roadway without having to use an access way: https://wiki.openstreetmap.org/wiki/Proposed_features/parking%3Dstreet_side The proposed tagging can be used on separate parking areas as well as with the parking:lane-scheme. It aims not only to differentiate such street-accompanying parking areas from others, especially "parking=surface", but also addresses a contradiction in the current use of the amenity=parking and parking:lane-scheme, which I would like to mention briefly at this point: the use of "layby"/"lay_by". The value "layby" was originally intended for forms of resting places, as they seem to be especially common in rural areas of Great Britain, Ireland or the US: short-stop rest-areas along through-traffic roads intended for breaks during a car-trip (see Wikipedia for a definition: https://en.wikipedia.org/wiki/Rest_area#Lay-bys). On areas with "amenity=parking" this key is also used in this sense (and mostly in Great Britain). Within the parking:lane-schema, however, the value "lay_by" (written with an underscore) has gained acceptance. According to the Wiki, this value is defined identically to the layby's mentioned above. Its actual use, however, differs from this and includes mainly street-side parking, as we address them in our proposal. With our proposal, we also want to resolve this contradiction. Above all, however, we would like to create more clarity about different types of parking in order to be able to distinguish between them. looking forward to your opinions and discussions, - Alex - (and Jeroen Hoek, another author of this proposal) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
