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_fea
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 ut
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 la
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 indee
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
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.
Tha
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
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 i
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
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 wit
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 i
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 pla
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
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=s
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 ameni
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 o
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
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 w
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 obvi
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 co
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 pa
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
>
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 matc
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 poin
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
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 us
I support parking=street_side, this is a much needed tag.
Janko
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
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.
28 matches
Mail list logo
