Re: [Tagging] Rooftop parking -> new parking=rooftop value?

[Martin Koppenhoefer]

2014-11-11 15:26 GMT+01:00 Holger Jeromin :

> > no, you won't have any overlapping ways any more, just one way, and all
> > overlapping geometries can become multipolygon relations with
> > appropriate layer tags (etc.)
>
> Ah.
> One untagged way and two MP-relations with the building and parking Tags.
>


you could also add the building tags to the way and use only one relation.
Hocuspocus multipolygon inheritance will go away sooner or later and
current software won't mess this up if you use different tags (AFAIK) ;-)



> The selection of multiple relations of one object is often easier as
> multiple ways in current editors. You are right.



yes, even more if there are many objects on the same spot, and if you have
to split the way for some linear attribute on part of it, you'll have no
probs with the relations.

cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rooftop parking -> new parking=rooftop value?

[Martin Koppenhoefer]

2014-11-11 15:26 GMT+01:00 Holger Jeromin :

> > Therefore, would prefer a generic tag that can be added to any
> feature,
> > e.g. location=rooftop.
> > what about the "surface" value, isn't rooftop (only) parking covered by
> > parking=surface? I am not completely sure languagewise, and the wiki
> > doesn't give any definition for the values...
>
> Think of an stone building, with grass on top on which you can park your
> car. surface= has to be grass, not rooftop.



I don't think taggingwise there would be any problem. You can tag
amenity=parking
parking=surface (i.e. not multistorey, not underground, you will park on
the surface)
surface=

you can also add location=rooftop, why not.

My question was whether a rooftop only parking wouldn't be included in
surface parkings.

cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rooftop parking -> new parking=rooftop value?

[Tobias Knerr]

On 12.11.2014 10:34, Pieren wrote:
> On Tue, Nov 11, 2014 at 11:22 PM, johnw  wrote:
>> 2014-11-11 12:53 GMT+01:00 Tobias Knerr :
> 
>>> Therefore, would prefer a generic tag that can be added to any feature,
>>> e.g. location=rooftop.
> 
> -1
> 'location' is already a bad keyword in OSM. Like "type", it is too
> generic and could be used for every thing.

Look at 'location' and 'type' in taginfo, and compare the two. While
type is indeed used for anything and everything, this is not at all the
case for location. People use the clearly defined location=underground
and that's it.

> I think the roof is part of the building 3d or levels mapping. We
> should not create a new use of "location" just for that. I could also
> imagine that in some buildings, the parking is somewhere in the middle
> and not necessarily on the top or on the bottom of the building, in
> which case you will have to invent a new tag for that.
> I would prefer something like "level=roof" or "level=3". Just where
> the parking(s) is in the building.

Of course level tagging would be the solution for anything below the
roof. However, roof mapping is more easily approachable than indoor
mapping (as you can use aerial imagery), so indoor mapping or even
knowing the number of levels should not be required for the ability to
map what's on top of the roof in my opinion. Using a level number would
also be likely not supported by regular (i.e. non-indoor) renderers,
while whatever=roof[top] might be.

Something like level=roof, on the other hand, would not be desirable if
there are multiple roof levels, and it also breaks the expectation that
the level key contains numeric values.

So I would prefer a specific tag for this situation. It doesn't have to
be location=rooftop, that was just my first idea.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rooftop parking -> new parking=rooftop value?

[johnw]

Well, if I was mapping a parking lot on a complex building, I assume that the 
building would have muliple parking lots connectedby ramps, bridges, or similar 
separations between the lots themselves. 

I asume that a building with muliple levels is either going to be mapped as a 
group of disparate areas grouped as a mulitpolygon, so they would all have 
there own levels=* tag, or there is some kind of relation thingie you guys are 
always talking about. Im sure having the item sitting on top, with level=roof 
makes pretty decent sense, but this is the reason I’m asking, as I’m unsure of 
the semantics required to accomplish my goal of tagging something as being "on 
the roof” or “on top of this building structure”


if that means only explicit numbers (level=3) as opposed to a relative term 
(level=attic, level=roof) that’s oaky - whatever gets the job done. 

J





> On Nov 12, 2014, at 8:33 PM, Mateusz Konieczny  wrote:
> 
> What about more complex buildings with multiple roofs?
> 
> 2014-11-12 12:27 GMT+01:00 johnw mailto:jo...@mac.com>>:
> 
> 
> level=roof sounds fine to me. Roof always gets special treatment (it’s 
> usually never a floor number)
> 
> 
> > On Nov 12, 2014, at 6:34 PM, Pieren  > > wrote:
> >
> > On Tue, Nov 11, 2014 at 11:22 PM, johnw  > > wrote:
> >> 2014-11-11 12:53 GMT+01:00 Tobias Knerr  >> >:
> >
> >>> Therefore, would prefer a generic tag that can be added to any feature,
> >>> e.g. location=rooftop.
> >
> > -1
> > 'location' is already a bad keyword in OSM. Like "type", it is too
> > generic and could be used for every thing.
> >
> >> On Nov 11, 2014, at 9:36 PM, Martin Koppenhoefer  >> >
> >> Those are excellent ideas. Then you could use location=rooftop (or similar)
> >> to place basically anything on the roof, including multistory or surface
> >> parking structures. Garden roofs come to mind.
> >
> > I think the roof is part of the building 3d or levels mapping. We
> > should not create a new use of "location" just for that. I could also
> > imagine that in some buildings, the parking is somewhere in the middle
> > and not necessarily on the top or on the bottom of the building, in
> > which case you will have to invent a new tag for that.
> > I would prefer something like "level=roof" or "level=3". Just where
> > the parking(s) is in the building.
> >
> > Pieren
> >
> > ___
> > 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

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rooftop parking -> new parking=rooftop value?

[Mateusz Konieczny]

What about more complex buildings with multiple roofs?

2014-11-12 12:27 GMT+01:00 johnw :

>
>
> level=roof sounds fine to me. Roof always gets special treatment (it’s
> usually never a floor number)
>
>
> > On Nov 12, 2014, at 6:34 PM, Pieren  wrote:
> >
> > On Tue, Nov 11, 2014 at 11:22 PM, johnw  wrote:
> >> 2014-11-11 12:53 GMT+01:00 Tobias Knerr :
> >
> >>> Therefore, would prefer a generic tag that can be added to any feature,
> >>> e.g. location=rooftop.
> >
> > -1
> > 'location' is already a bad keyword in OSM. Like "type", it is too
> > generic and could be used for every thing.
> >
> >> On Nov 11, 2014, at 9:36 PM, Martin Koppenhoefer <
> dieterdre...@gmail.com>
> >> Those are excellent ideas. Then you could use location=rooftop (or
> similar)
> >> to place basically anything on the roof, including multistory or surface
> >> parking structures. Garden roofs come to mind.
> >
> > I think the roof is part of the building 3d or levels mapping. We
> > should not create a new use of "location" just for that. I could also
> > imagine that in some buildings, the parking is somewhere in the middle
> > and not necessarily on the top or on the bottom of the building, in
> > which case you will have to invent a new tag for that.
> > I would prefer something like "level=roof" or "level=3". Just where
> > the parking(s) is in the building.
> >
> > Pieren
> >
> > ___
> > 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] Rooftop parking -> new parking=rooftop value?

[johnw]

level=roof sounds fine to me. Roof always gets special treatment (it’s usually 
never a floor number)


> On Nov 12, 2014, at 6:34 PM, Pieren  wrote:
> 
> On Tue, Nov 11, 2014 at 11:22 PM, johnw  wrote:
>> 2014-11-11 12:53 GMT+01:00 Tobias Knerr :
> 
>>> Therefore, would prefer a generic tag that can be added to any feature,
>>> e.g. location=rooftop.
> 
> -1
> 'location' is already a bad keyword in OSM. Like "type", it is too
> generic and could be used for every thing.
> 
>> On Nov 11, 2014, at 9:36 PM, Martin Koppenhoefer 
>> Those are excellent ideas. Then you could use location=rooftop (or similar)
>> to place basically anything on the roof, including multistory or surface
>> parking structures. Garden roofs come to mind.
> 
> I think the roof is part of the building 3d or levels mapping. We
> should not create a new use of "location" just for that. I could also
> imagine that in some buildings, the parking is somewhere in the middle
> and not necessarily on the top or on the bottom of the building, in
> which case you will have to invent a new tag for that.
> I would prefer something like "level=roof" or "level=3". Just where
> the parking(s) is in the building.
> 
> Pieren
> 
> ___
> 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] Rooftop parking -> new parking=rooftop value?

[Pieren]

On Tue, Nov 11, 2014 at 11:22 PM, johnw  wrote:
> 2014-11-11 12:53 GMT+01:00 Tobias Knerr :

>> Therefore, would prefer a generic tag that can be added to any feature,
>> e.g. location=rooftop.

-1
'location' is already a bad keyword in OSM. Like "type", it is too
generic and could be used for every thing.

> On Nov 11, 2014, at 9:36 PM, Martin Koppenhoefer 
> Those are excellent ideas. Then you could use location=rooftop (or similar)
> to place basically anything on the roof, including multistory or surface
> parking structures. Garden roofs come to mind.

I think the roof is part of the building 3d or levels mapping. We
should not create a new use of "location" just for that. I could also
imagine that in some buildings, the parking is somewhere in the middle
and not necessarily on the top or on the bottom of the building, in
which case you will have to invent a new tag for that.
I would prefer something like "level=roof" or "level=3". Just where
the parking(s) is in the building.

Pieren

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rooftop parking -> new parking=rooftop value?

[johnw]

> 
> First Principle? 

> However in a multistory buliding .. what are people coming to the building 
> for? Should 'we' not map the purpose of the building

The purpose of the building is indeed retail (almost always), but the purpose 
of the map is navigation. 

I wish to accurately tag and render something you would see on your GPS while 
driving in the vicinity of the mall. Some of them are quite complex - I’d like 
to think I have a very good idea of my surroundings, but while trying to leave 
a very large and complicated shopping mall rooftop, it was impossible for me to 
visualize the warren of paths on top of the roof of the building I was on. I I 
was trying to exit on one side, ended up exiting on another. 

> Provision of parking may be important .. but it is not the most important 
> thing. Only a single purpose parking complex has the sole function of 
> providing parking.   

Yep which is why I thought having a tag parking=roofttop for an area tagged as 
amenity=parking that is (almost always) contained *inside* an area tagged with 
building=* would warrant different tagging or rendering. 



> Second .. Effort? 
> A miltistory thing will have many surfaces, one floor may be concrete, 
> another carpet, another stone. Tagging these in some sensible way may be fine

All for it. 

> .. but how will they be used? 

shop=mall is a good place to start. Indoor mapping is really difficult because 
of the scale of building vs the road system we are mapping, and the overlapping 
nature of multistory buildings, so a system hasn’t been developed into 
something useable for a basic mapper yet (IE; me, mapping in iD), and 
considering the difficulty of turning a building outline into an accurate 
representation of it’s internals, it will almost impossible for for satellite 
imagery tracers. 

BUT - This is one of the few cases where the road system actually goes on top 
of buildings. There are few other cases where a common class of buildings that  
are *under* a road system (there are thousands of surface rooftop parking lots 
in Japan, and many rooftop multi-storey ones) and still have the building 
itself be visible for a navigation/mapping purpose. 

These roof parking lots seem like an easy thing to tag, and is still unrelated 
to what is going on inside the building. 

I thought changing the opacity of it's render would give more priority to the 
points with shop tags / indoor tags that will eventually populate the building, 
but would let the parking layout visible on the roof for car navigation. 

> And is it worth the effort? 

It’s about 10m for me to map out a single parking lot, to go with the hour or 
so I would spend mapping the basics of a small mall. I tend to spend a lot of 
time mapping retail places, because I assume the detail will be very useful to 
people wanting to use a map to navigate to and around large retail 
establishments, such as the rare large malls here in suburban/rural Japan ( ~ 2 
million people with 3 malls in my prefecture, and ~ 15 large shopping centers.) 

> Considering the quality of the map in some parts of the world would not these 
> efforts be better spent in improving the map elsewhere? :) 

I’m turing the soup of unaligned & outdated unclassified/residential roads into 
something more usable in my neck of the woods - getting some more tags isn’t 
going to slow me down too much - I just want to describe what cars and 
pedestrians are going to use, or places they want to visit. ^_^

Now that the tagging structure can handle roads, driveways, tracks and trails 
with very high levels of detail, the effort to refine the tags for even smaller 
and more local conditions, along with more detailed tagging of areas is 
becoming the purview of the tagging groups issues, right? Until there is some 
drastic change to the main structure of the tagging system, the future of tag 
refinement will be ever more increasing tags for detail of in missing areas, 
and refining and codifying the messes of existing tags to make tagging/parsing 
easier.  Right?

The frist time you run into a tagging situation that seems unwieldly or 
missing, and decend into the wiki to figure out how to tag something, it really 
knocks the wind out of new taggers. Train stations nearly sent me packing.

If we have enough detailed tags to handle *anything* taggers can find - 
codified and explained on the wiki, properly made presets for them in iD, and 
renders in  -carto, the world will eventually be mapped to our satisfaction by 
an increasing number of amateurs.


Javbw 






___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rooftop parking -> new parking=rooftop value?

[Warin]

On 12/11/2014 5:20 AM, tagging-requ...@openstreetmap.org wrote:
  
Date: Tue, 11 Nov 2014 15:26:48 +0100

From: Holger Jeromin 
To: tagging@openstreetmap.org
Subject: Re: [Tagging] Rooftop parking -> new parking=rooftop value?
Message-ID: 
Content-Type: text/plain; charset=utf-8

Martin Koppenhoefer wrote on 11.11.2014 13:36:


2014-11-11 12:53 GMT+01:00 Tobias Knerr
 On 11.11.2014 06:38, johnw wrote:
 > I assume there is a need to create a new parking=rooftop or similar tag, 
which can then be used to create more accurate renderers (perhaps by also placing 
the parking=rooftop tag onto the service=parking isle service roads, so they are 
similarly (translucently?) rendered.
 The issue of service roads already hints at a larger problem: There are
 many different things that can be on a rooftop, not just parking.

 Therefore, would prefer a generic tag that can be added to any feature,
 e.g. location=rooftop.
what about the "surface" value, isn't rooftop (only) parking covered by
parking=surface? I am not completely sure languagewise, and the wiki
doesn't give any definition for the values...

Think of an stone building, with grass on top on which you can park your
car. surface= has to be grass, not rooftop.



First Principle?
There is a thinking that what is seen from the air/satellite is what 
should be mapped.
However in a multistory buliding .. what are people coming to the 
building for? Should 'we' not map the purpose of the building rather 
than just the air/satellite view?For a shopping complex .. that would be 
each shop - location, name and serevice. Provision of parking may be 
important .. but it is not the most important thing. Only a single 
purpose parking complex has the sole function of providing parking.


Second .. Effort?
A miltistory thing will have many surfaces, one floor may be concrete, 
another carpet, another stone. Tagging these in some sensible way may be 
fine .. but how will they be used? And is it worth the effort? 
Considering the quality of the map in some parts of the world would not 
these efforts be better spent in improving the map elsewhere? :)


-
Warin
Presently considering a holiday in India .. and making editorials there 
to get the routing working (and adding things as I see them while doing 
those corrections).



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rooftop parking -> new parking=rooftop value?

[johnw]

> 2014-11-11 12:53 GMT+01:00 Tobias Knerr  >:



> Therefore, would prefer a generic tag that can be added to any feature,
> e.g. location=rooftop.


with

> On Nov 11, 2014, at 9:36 PM, Martin Koppenhoefer  
> wrote:


> what about the "surface" value, isn't rooftop (only) parking covered by 
> parking=surface?


Those are excellent ideas. Then you could use location=rooftop (or similar) to 
place basically anything on the roof, including multistory or surface parking 
structures. Garden roofs come to mind. 

For some reason, the school I teach at keeps grass covering the majority of the 
roof, and no one is up there, except 2-3 times a year. Pools, walkways, 
antennas, power and comm antennas, etc. are good too. 

There are some GIANT comm towers the sprout out of buildings here in Japan - 
large 10 story buildings with a 50m tower on top for microwave and cell tower 
antennas.

you can see one dead-center in my wikipedia pic for Maebashi City. 
http://en.wikipedia.org/wiki/Maebashi#mediaviewer/File:Maebashi20080227.jpg 


There is a big white antenna on a building ont he right side of the pic.

so, I guess the next goal is to get parking=multistory rendering correctly - 
there is no example on the wiki, but I *think* multi-storey does not have a 
unique render - which (in 2009) was leading to shit tagging to get a different 
render. 

Javbw


> 
> 
> 
> On 11.11.2014 06:38, johnw wrote:
> > I assume there is a need to create a new parking=rooftop or similar tag, 
> > which can then be used to create more accurate renderers (perhaps by also 
> > placing the parking=rooftop tag onto the service=parking isle service 
> > roads, so they are similarly (translucently?) rendered.
> 
> The issue of service roads already hints at a larger problem: There are
> many different things that can be on a rooftop, not just parking.
> 
> 
> 
> 
> what about the "surface" value, isn't rooftop (only) parking covered by 
> parking=surface? I am not completely sure languagewise, and the wiki doesn't 
> give any definition for the values...
> 
> 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] Rooftop parking -> new parking=rooftop value?

[Holger Jeromin]

Martin Koppenhoefer wrote on 11.11.2014 12:21:

> 2014-11-11 11:09 GMT+01:00 Holger Jeromin
> > Me similarily, but would propose to use a multipolygon relation
> instead.
> > That's why they are there, overlapping ways are hard to maintain and
> > more difficult to spot.
> Instead?
> Adding a relation to the two overlapping ways seems not making it
> easier. The building (parts?) have the same outline, so they have to
> overlap in the first place.
> no, you won't have any overlapping ways any more, just one way, and all
> overlapping geometries can become multipolygon relations with
> appropriate layer tags (etc.)

Ah.
One untagged way and two MP-relations with the building and parking Tags.

The selection of multiple relations of one object is often easier as
multiple ways in current editors. You are right.

-- 
regards
Holger


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rooftop parking -> new parking=rooftop value?

[Holger Jeromin]

Martin Koppenhoefer wrote on 11.11.2014 13:36:

> 2014-11-11 12:53 GMT+01:00 Tobias Knerr
> On 11.11.2014 06:38, johnw wrote:
> > I assume there is a need to create a new parking=rooftop or similar 
> tag, which can then be used to create more accurate renderers (perhaps by 
> also placing the parking=rooftop tag onto the service=parking isle service 
> roads, so they are similarly (translucently?) rendered.
> The issue of service roads already hints at a larger problem: There are
> many different things that can be on a rooftop, not just parking.
> 
> Therefore, would prefer a generic tag that can be added to any feature,
> e.g. location=rooftop.
> what about the "surface" value, isn't rooftop (only) parking covered by
> parking=surface? I am not completely sure languagewise, and the wiki
> doesn't give any definition for the values...

Think of an stone building, with grass on top on which you can park your
car. surface= has to be grass, not rooftop.

-- 
Holger


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rooftop parking -> new parking=rooftop value?

[Martin Koppenhoefer]

2014-11-11 12:53 GMT+01:00 Tobias Knerr :

> On 11.11.2014 06:38, johnw wrote:
> > I assume there is a need to create a new parking=rooftop or similar tag,
> which can then be used to create more accurate renderers (perhaps by also
> placing the parking=rooftop tag onto the service=parking isle service
> roads, so they are similarly (translucently?) rendered.
>
> The issue of service roads already hints at a larger problem: There are
> many different things that can be on a rooftop, not just parking.
>
> Therefore, would prefer a generic tag that can be added to any feature,
> e.g. location=rooftop.
>


what about the "surface" value, isn't rooftop (only) parking covered by
parking=surface? I am not completely sure languagewise, and the wiki
doesn't give any definition for the values...

cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rooftop parking -> new parking=rooftop value?

[Tobias Knerr]

On 11.11.2014 06:38, johnw wrote:
> I assume there is a need to create a new parking=rooftop or similar tag, 
> which can then be used to create more accurate renderers (perhaps by also 
> placing the parking=rooftop tag onto the service=parking isle service roads, 
> so they are similarly (translucently?) rendered. 

The issue of service roads already hints at a larger problem: There are
many different things that can be on a rooftop, not just parking.

Therefore, would prefer a generic tag that can be added to any feature,
e.g. location=rooftop.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rooftop parking -> new parking=rooftop value?

[Martin Koppenhoefer]

2014-11-11 11:09 GMT+01:00 Holger Jeromin :

> > Me similarily, but would propose to use a multipolygon relation instead.
> > That's why they are there, overlapping ways are hard to maintain and
> > more difficult to spot.
>
> Instead?
>
> Adding a relation to the two overlapping ways seems not making it
> easier. The building (parts?) have the same outline, so they have to
> overlap in the first place.



no, you won't have any overlapping ways any more, just one way, and all
overlapping geometries can become multipolygon relations with appropriate
layer tags (etc.)

cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rooftop parking -> new parking=rooftop value?

[johnw]

I was thinking of just.. Um.. drawing an area of the building, with levels=x, 
layer=1, then drawing the parking lot on top of it (it usually is a bit smaller 
and less than 100% of the top, elevators and AC and all), and then tagging the 
parking with Amenity=parking & parking=rooftop / layer=2

Here’s the place I’m tracing/aligning now in OSM. 
https://www.google.com/maps/@36.3557609,139.1296344,438m/data=!3m1!1e3 


Here’s my local shopping mart. 
https://www.google.com/maps/@36.4191102,139.2343137,109m/data=!3m1!1e3 


Both are parking only on the roof.  I was just thinking that having them render 
differently would be necessary, and since they are different than other 
parking, they might need a new tag


J

> On Nov 11, 2014, at 7:09 PM, Holger Jeromin  wrote:
> 
> Martin Koppenhoefer wrote on 11.11.2014 11:01:
> 
>> 2014-11-11 10:56 GMT+01:00 Holger Jeromin
>> >I would suggest two overlapping ways:
>>building=yes
>>amenity=parking
>>parking=multi-story
>>building:levels=5
>>building:min_levels=2
>>layer=1
>> 
>>and
>>building=retail
>>building:levels=2
>>shop=department_store
>> Me similarily, but would propose to use a multipolygon relation instead.
>> That's why they are there, overlapping ways are hard to maintain and
>> more difficult to spot.
> 
> Instead?
> 
> Adding a relation to the two overlapping ways seems not making it
> easier. The building (parts?) have the same outline, so they have to
> overlap in the first place.
> 
> -- 
> regards
> Holger
> 
> 
> ___
> 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] Rooftop parking -> new parking=rooftop value?

[Holger Jeromin]

Martin Koppenhoefer wrote on 11.11.2014 11:01:

> 2014-11-11 10:56 GMT+01:00 Holger Jeromin
>  I would suggest two overlapping ways:
> building=yes
> amenity=parking
> parking=multi-story
> building:levels=5
> building:min_levels=2
> layer=1
> 
> and
> building=retail
> building:levels=2
> shop=department_store
> Me similarily, but would propose to use a multipolygon relation instead.
> That's why they are there, overlapping ways are hard to maintain and
> more difficult to spot.

Instead?

Adding a relation to the two overlapping ways seems not making it
easier. The building (parts?) have the same outline, so they have to
overlap in the first place.

-- 
regards
Holger


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rooftop parking -> new parking=rooftop value?

[Martin Koppenhoefer]

2014-11-11 10:56 GMT+01:00 Holger Jeromin :

> I would suggest two overlapping ways:
> building=yes
> amenity=parking
> parking=multi-story
> building:levels=5
> building:min_levels=2
> layer=1
>
> and
> building=retail
> building:levels=2
> shop=department_store
>



Me similarily, but would propose to use a multipolygon relation instead.
That's why they are there, overlapping ways are hard to maintain and more
difficult to spot.

cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rooftop parking -> new parking=rooftop value?

[Holger Jeromin]

johnw wrote on 11.11.2014 06:38:

> I’m not sure of other countries, but at least in the US, parking on
> top of retail structures is exceedingly rare - usually there are
> adjacent multi-story parking structures. It always seems that there
> is some kind of code or cost savings preventing it, always forcing it
> to be underground or lower level parking inside the building itself,
> which really isn’t mappable.

> In Japan, rooftop parking on multistory buildings (bottom floors are
> shops, and the roof is parking) is quite common.  sometimes there is
> more than one upper floor used for parking - it was such a surprise
> to find a 5 story Costco, with 2 bottom floors for the retail space,
> and the top 3 for car parking.

Ok, you want to have one way for the whole building. I dont think this
would work.

What differs a full 5 level multi-story parking and a
4 level parking on top of one shop level? Why use rooftop instead of
multi-story?
Where is the border when to use rooftop and when multi-story? Majority
of levels used not for parking?

Suppose a way with the tags:
building=yes
building:levels=5
amenity=parking
parking=rooftop
shop=department_store

How much of the building is the department_store, how much parking?
What about a amenity=school? we cannot reuse the amenity tag on the same
way.

I would suggest two overlapping ways:
building=yes
amenity=parking
parking=multi-story
building:levels=5
building:min_levels=2
layer=1

and
building=retail
building:levels=2
shop=department_store

If we have only the roof used, we could map it as surface with a
min_height and layer.

> I assume there is a need to create a new parking=rooftop or similar
> tag, which can then be used to create more accurate renderers
> (perhaps by also placing the parking=rooftop tag onto the
> service=parking isle service roads, so they are similarly
> (translucently?) rendered.

translucent should be IMO only indoor (aka tunnel) ways.

-- 
greetings
Holger


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Rooftop parking -> new parking=rooftop value?

[johnw]

I’m not sure of other countries, but at least in the US, parking on top of 
retail structures is exceedingly rare - usually there are adjacent multi-story 
parking structures. It always seems that there is some kind of code or cost 
savings preventing it, always forcing it to be underground or lower level 
parking inside the building itself, which really isn’t mappable. 

In Japan, rooftop parking on multistory buildings (bottom floors are shops, and 
the roof is parking) is quite common.  sometimes there is more than one upper 
floor used for parking - it was such a surprise to find a 5 story Costco, with 
2 bottom floors for the retail space, and the top 3 for car parking. 

With good satellite coverage, the roof lots are easily visible and taggable.

Most larger shopping malls, large retail stores, and even larger local shops 
all have rooftop parking, most with exposed (mappable) driveway ramp “bridges". 
that are also easily rendered. Several of the food markets in my small suburban 
town have rooftop parking. 

I assume there is a need to create a new parking=rooftop or similar tag, which 
can then be used to create more accurate renderers (perhaps by also placing the 
parking=rooftop tag onto the service=parking isle service roads, so they are 
similarly (translucently?) rendered. 

In parking’s wiki discussion page, rooftop was going to be suggested in 2009, 
as people were using the bridge=yes tag to get a render of a “parking lot 
bridge”, which is just mapping for the renderer. 

http://wiki.openstreetmap.org/wiki/Talk:Tag:amenity%3Dparking#Parking_on_top_of_buildings_.28rooftop_parking.29_and_multi-level_parking_.28parking_garages.29

I want to tag these correctly, and then go to -carto and get them rendered 
correctly. 

Does the parking=rooftop value sound like a good idea, or is this something 
completely handled with layer=*?

Javbw
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging