Re: [Tagging] Points vs Polygons

[Paul Allen]

On Fri, 24 Apr 2020 at 10:05, Martin Koppenhoefer 
wrote:

> Am Do., 23. Apr. 2020 um 17:14 Uhr schrieb Paul Allen  >:
>
>
>>   I've had to fix enough addresses
>> (mainly incorrect postcodes but sometimes incorrect or missing
>> street names and even cities) that having the same information
>> in two places is undesirable.
>>
>
> may depend on the kind of problem. For postcodes the situation may be
> different than for housenumbers?
>

They're pretty much the same from the perspective of duplicated data.  If
it's
wrong in two places there's a strong possibility that only one will get
fixed.  If
it's noticed at all.

In my context, it is also quite common to have distinct housenumbers like 1
> and 3 and 5, each as a node, each assigned to entrances that lead into the
> same shop, while the business uses either an address by choosing one of
> them (maybe the actual entrance, but maybe the entrance it used to use
> years ago) or more commonly an address like housenumer=1-5 (or 1/3/5) or in
> OSM syntax 1;3;5
>

I've mapped a few of those.  Separating walls were removed in most of them,
leaving what I mapped as a single larger building.  I could have mapped the
address chosen by the business but instead went with 13-14 so that people
wouldn't wonder why the sequence of house numbers was 12, 14, 15 (yes,
they're all on the same side of the road).  As for postcodes, it is a bank
so it has its own individual postcode (assigned back in the days when
there was no electronic funds transfer so banks received a lot of
cheques for verification and clearance).

Two house numbers applying to a single business in a case like that
is not really a factor in deciding whether to use a single object for
building and business, two coincident objects or a building with a
node.  More of a problem is when buildings get subdivided and
retain the same address.  I handled that as a building with
two nodes, mainly to avoid somebody later assuming one
of the addresses of two adjacent buildings was wrong.

>
>
>>   The more so when that same
>> information is on coincident polygons that iD makes hard to
>> manipulate, or even notice.
>>
>
> let's not discuss the problems of individual software solutions, they will
> adapt sooner or later.
>

Until they do then many mappers will tag things in the way that the software
solution makes easiest.  That's human nature.  If we insist there is only
one correct way to do it, and that the one correct way is very hard to
achieve
in a widely-used software solution, people will either do it a different
way
(contrary to our desires) or stop mapping.


> When there are polygons with coincident information, there is not issue,
> when they are different, it may indicate either a data problem (error) or
> the node tags will override the polygon defaults. It is not completely
> clear, both interpretations are around.
>

The problem is that, with one software solution, fixing those types of
errors is
hard.  In fact, with that solution you may not even notice the discrepancy
exists:
if you want to change the business and you get the tags for the business
when
you click on the coincident objects then you won't see the different details
of the coincident building.  Until that changes, insisting on coincident
objects
is likely to result in data inconsistencies.

>
>> But there are cases where using a node rather than a building (not just an
>> area but a building=*) for a POI means the name doesn't get rendered.
>> Clubs
>> and crafts, for example.
>>
>
> it doesn't matter, as it is just refering to a single piece of rendering
> software. Everybody can display any name they like.
>

But one particular rendering is intended for use by mappers to check their
work.  If something isn't displayed in that rendering then some mappers
will find an alternative (but still valid) way of tagging the item.
Purists will
throw up their hand in horror, but that's the reality.

>
> That's just another reason why people tag the same object as both a
>> building
>> and a business rather than making it two objects.  It makes clear that
>> there is
>> a relationship between the two rather than it possibly being an accident.
>>
>
> problem is that the kind of relationship they are modelling (identity) is
> incorrect.
>

>From the perspective of a purist, that is correct.  From the perspective of
a pragmatist, working with the tools we have right now, that's something
that can be dealt with at a future time when we have better tools.  I think
the pragmatists outnumber the purists.

I've tried not to advocate that any particular approach is the one correct
way to do it.  I'm arguing that, with the tools we have, there are
alternatives
with pros and cons.  In an ideal world there would be one single method
that handles all situations perfectly.  We live in an imperfect world.

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

Re: [Tagging] Points vs Polygons

[Martin Koppenhoefer]

Am Do., 23. Apr. 2020 um 17:14 Uhr schrieb Paul Allen :

> I do not see why you would have to remove the address information from the
>> building when you add it to another object with the same address (like a
>> shop).
>>
>
> DRY.  Having the same address info for the building and the business
> makes it more likely that if the information is found to be incorrect only
> one of the copies will be corrected.
>


"more likely" is even an understatement, it will be impossible to have
different address information when there is only one object with address
tags, naturally. But if it is incorrect, you will have twice the errors.
When there are inconsistencies that could be seen in the data (like point
inside a polygon has different address), it can be used for quality checks
and someone can go there and verify which is correct. There are pros and
cons to both approaches.



>   I've had to fix enough addresses
> (mainly incorrect postcodes but sometimes incorrect or missing
> street names and even cities) that having the same information
> in two places is undesirable.
>


may depend on the kind of problem. For postcodes the situation may be
different than for housenumbers? In my context, it is also quite common to
have distinct housenumbers like 1 and 3 and 5, each as a node, each
assigned to entrances that lead into the same shop, while the business uses
either an address by choosing one of them (maybe the actual entrance, but
maybe the entrance it used to use years ago) or more commonly an address
like housenumer=1-5 (or 1/3/5) or in OSM syntax 1;3;5



>   The more so when that same
> information is on coincident polygons that iD makes hard to
> manipulate, or even notice.
>


let's not discuss the problems of individual software solutions, they will
adapt sooner or later. When there are polygons with coincident information,
there is not issue, when they are different, it may indicate either a data
problem (error) or the node tags will override the polygon defaults. It is
not completely clear, both interpretations are around.


> it could also be seen useful redundancy that strengthens the stability (if
>> you have verified the address information for the business, even if someone
>> "adjusts" the positions of the buildings and oversees the POIs, you will
>> still have the correct address on the POI.
>>
>
> But there are cases where using a node rather than a building (not just an
> area but a building=*) for a POI means the name doesn't get rendered.
> Clubs
> and crafts, for example.
>


it doesn't matter, as it is just refering to a single piece of rendering
software. Everybody can display any name they like.



>
>
>> I.e. explicit tagging is more reliable, and can be seen as a confirmation
>> that the information has been actually verified, compared to a POI without
>> addressing information lying inside a given address boundary (think about
>> someone placing a POI by memory roughly where it should be).
>>
>
> That's just another reason why people tag the same object as both a
> building
> and a business rather than making it two objects.  It makes clear that
> there is
> a relationship between the two rather than it possibly being an accident.
>


problem is that the kind of relationship they are modelling (identity) is
incorrect.



> Each approach has benefits in certain situations.  I don't think any of
> them
> deserve the "You must not do it that way" injunctions we sometimes see
> here.
>


+1

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

Re: [Tagging] Points vs Polygons

[Paul Allen]

On Thu, 23 Apr 2020 at 15:08, Martin Koppenhoefer 
wrote:

>
> Am Mi., 22. Apr. 2020 um 14:12 Uhr schrieb Paul Allen  >:
>
>> This is all true.  And in an ideal world we'd map the building and its
>> occupying
>> object as  two separate-but-coincident objects.  This isn't an ideal
>> world. :(
>>
>
>
>> Problem 2: Duplication of address info.  The building has an address
>> irrespective of the occupying object.  But it is convenient for
>> consumers querying the occupying object to get the address of
>> the occupying organization in a single step.  "Don't repeat yourself"
>> is a good maxim, but one we must flout with coincident objects.
>> Unless you want the pain of not putting an address on the building
>> if it is occupied, but transferring the address from the occupier to
>> the building prior to deleting the occupier when the building
>> becomes vacant.
>>
>
>
> I do not see why you would have to remove the address information from the
> building when you add it to another object with the same address (like a
> shop).
>

DRY.  Having the same address info for the building and the business
makes it more likely that if the information is found to be incorrect only
one of the copies will be corrected.  I've had to fix enough addresses
(mainly incorrect postcodes but sometimes incorrect or missing
street names and even cities) that having the same information
in two places is undesirable.  The more so when that same
information is on coincident polygons that iD makes hard to
manipulate, or even notice.

On a sidenote, while it may not be desirable from a "clean" database
> approach to have duplicate information (when the enclosing building has an
> address, you will not have to repeat the same information on the contained
> objects),
>

It makes it easier on consumers querying objects.  Who may not know that
they queried a node for a business without an address because the address
is on the enclosing building.

it could also be seen useful redundancy that strengthens the stability (if
> you have verified the address information for the business, even if someone
> "adjusts" the positions of the buildings and oversees the POIs, you will
> still have the correct address on the POI.
>

But there are cases where using a node rather than a building (not just an
area but a building=*) for a POI means the name doesn't get rendered.  Clubs
and crafts, for example.


> I.e. explicit tagging is more reliable, and can be seen as a confirmation
> that the information has been actually verified, compared to a POI without
> addressing information lying inside a given address boundary (think about
> someone placing a POI by memory roughly where it should be).
>

That's just another reason why people tag the same object as both a building
and a business rather than making it two objects.  It makes clear that
there is
a relationship between the two rather than it possibly being an accident.

Each approach has benefits in certain situations.  I don't think any of them
deserve the "You must not do it that way" injunctions we sometimes see
here.

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

Re: [Tagging] Points vs Polygons

[Martin Koppenhoefer]

Am Mi., 22. Apr. 2020 um 14:12 Uhr schrieb Paul Allen :

> This is all true.  And in an ideal world we'd map the building and its
> occupying
> object as  two separate-but-coincident objects.  This isn't an ideal
> world. :(
>


> Problem 2: Duplication of address info.  The building has an address
> irrespective of the occupying object.  But it is convenient for
> consumers querying the occupying object to get the address of
> the occupying organization in a single step.  "Don't repeat yourself"
> is a good maxim, but one we must flout with coincident objects.
> Unless you want the pain of not putting an address on the building
> if it is occupied, but transferring the address from the occupier to
> the building prior to deleting the occupier when the building
> becomes vacant.
>


I do not see why you would have to remove the address information from the
building when you add it to another object with the same address (like a
shop). While it may be true from a city council point of view, that every
address is only assigned once to a building/site, it isn't implying we
cannot have the same address properties for several OSM objects. For
example in Italy, where housenumbers are assigned to entrances rather than
buildings or sites, it is inevitable to repeat the same address information
when there are several businesses with the same entrance door (it is not
practical to draw polygons for addresses because the same place will
typically have several entrance doors and you may not know which addresses
are leading to which space, or which address is the one the business is
using (if there are several possibilities). It would also seem crazy
overkill to create relations between entrances (assigned addresses) and
occupying uses, just to avoid repeating address information.


On a sidenote, while it may not be desirable from a "clean" database
approach to have duplicate information (when the enclosing building has an
address, you will not have to repeat the same information on the contained
objects), it could also be seen useful redundancy that strengthens the
stability (if you have verified the address information for the business,
even if someone "adjusts" the positions of the buildings and oversees the
POIs, you will still have the correct address on the POI. I.e. explicit
tagging is more reliable, and can be seen as a confirmation that the
information has been actually verified, compared to a POI without
addressing information lying inside a given address boundary (think about
someone placing a POI by memory roughly where it should be).





> And introduces problem 3: some
> types of entity render if they have an area and building=yes
> but do not render (not even a label) if they are nodes.  Clubs and crafts
> are two examples I can think of.  As for healthcare=alternative, if
> the building has an addr;housename then that is used as the label
> rather than the name=*.
>
> Our tagging practices are heavily influenced by the limitations of
> the tools we use...
>


IMHO looking at the details which tool supports which way of representation
is not helpful. Map as you believe is "best", thereby also adding more
incentive for the people who build rendered maps or editors, to cater for
this way of mapping. You should not care whether the current OSM Carto
visualizes areas, nodes or both. It may change at any time, and there will
be many other applications that will support nodes (or areas).

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

Re: [Tagging] Points vs Polygons

[Warin]

On 20/4/20 1:51 am, Robert Castle wrote:

Hi Everyone,

I'm new to OSM and have been I've been making some edits on Main 
Street of my hometown. All the buildings seem to have been mapped, but 
many of the businesses are not mapped or have incomplete information, 
so I've been adding in the business names that aren't there and 
editing the ones that have incomplete info. I noticed that some 
businesses are polygons whereas others are points within a polygon. I 
was wondering which way is correct.


Best,
Rob




Welcome!

You can see the diversity of views in answer to your question.

Presently .. do what seems right for you and the things you map.


Some things in OSM have;

more than one way to map them.

one way that is better than other ways of mapping.


Don't be too fussed, as long as the tags make sense to a human someone 
can figure out what was meant and translate it into the latest OSM 
tagging method... and that does change over time.


Please do make changeset comments as an aid to what was mapped.. it 
helps is you comeback to it some time later.


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

Re: [Tagging] Points vs Polygons

[John Willis via Tagging]

> On Apr 22, 2020, at 8:38 PM, Martin Koppenhoefer  > wrote:
> 
> but the building is also a thing, it has its own properties, e.g. start_date, 
> wikipedia reference, architect, operator, name, height, etc 
> 
> yes, often you can understand which tag belongs to which object, when several 
> objects are represented by one OpenStreetMap object (and that’s why we 
> tolerate this kind of representation), but strictly, you can’t even know 
> whether the name belongs to the building or to the occupant (it “works” 
> because you assume that buildings mostly don’t have names).


Yep, I do this because I assume the buildings have names and attributes that 
need to be labeled beyond the encompassing landuse. 

every building at the mall is not named “the mall”. 

the landuse=retail area is all “ the shopping mall”  - the named parking lots, 
the access roads, the hedges along the fence, etc.

Everything inside this area is "the mall”. 

a retail building here is 3 levels, named “south Mall”. it is part of “the 
mall”.

this other retail building is a deptartment store. it is a giant named anchor 
store. it has 2 levels. it has the shop tagging on it. 

This pin over her is a small shop the south building. that pin is “in the mall” 
and “in the south building” and has all the tagging for this small shop. 

It completely baffles me that the way to tag one collection of buildings and 
amenities sitting on a named area/landuse is fine for one type, yet somehow a 
contentious issue when it comes to tagging another set of buildings and 
amenities that sit on an area. 

there are many retail establishments that are the area (malls, shopping 
centers, big-box stores), many that take the building (many supermarkets or 
similar), and then a myriad of pins that may be on any of these objects to 
represent smaller shops inside.

 Shopping centers in particular have usually unknown official names (“parkway 
shopping” printed on the top of the sign) and then a collection of road-facing 
retail buildings that people see. having the shopping center 
(shop=shopping_centre) labeled as a pin in the middle of the parking lot is not 
great mapping IMO. 

A large supermarket tagged onto building may sit on a differently named landuse 
(a shopping center), and have a pin inside the building to represent the small 
coffee shop or bank or similar tiny shop “inside” the supermarket as well, 

Very similar to a Hospital which is a giant named area, a named individual 
hospital building, and pin for a convenience store in the basement. 

keeping this flexibility better represents reality. 

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

Re: [Tagging] Points vs Polygons

[Paul Allen]

On Wed, 22 Apr 2020 at 12:40, Martin Koppenhoefer 
wrote:

>
> but the building is also a thing, it has its own properties, e.g.
> start_date, wikipedia reference, architect, operator, name, height, etc
>

This is all true.  And in an ideal world we'd map the building and its
occupying
object as  two separate-but-coincident objects.  This isn't an ideal world.
:(

Problem 1.  A popular editor makes it VERY hard to deal with coincident
objects.  All it would take would be a modifier key (such as control) to
cycle
through all coincident objects sharing the node or way clicked on.  Instead
you get whichever object it decides to give you and can't get at the
other(s).
The only way I've found is to disconnect a node, drag that node so it is
no longer coincident with other objects, click on the now separated
objects until I find the one I want, modify it, move the node back to
where it was.

Maybe there's a simple, obvious way of doing it that I'm missing, but I
haven't found it.  For as long as that editor makes it painful to have
coincident objects then people will avoid using them unless forced
to for other reasons (there is no other way of mapping some aspect
of one of the objects that they consider a necessary feature).

Problem 2: Duplication of address info.  The building has an address
irrespective of the occupying object.  But it is convenient for
consumers querying the occupying object to get the address of
the occupying organization in a single step.  "Don't repeat yourself"
is a good maxim, but one we must flout with coincident objects.
Unless you want the pain of not putting an address on the building
if it is occupied, but transferring the address from the occupier to
the building prior to deleting the occupier when the building
becomes vacant.

Using a node for the occupying entity gets rid of problem 1 but
does not get rid of problem 2.  And introduces problem 3: some
types of entity render if they have an area and building=yes
but do not render (not even a label) if they are nodes.  Clubs and crafts
are two examples I can think of.  As for healthcare=alternative, if
the building has an addr;housename then that is used as the label
rather than the name=*.

Our tagging practices are heavily influenced by the limitations of
the tools we use...

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

Re: [Tagging] Points vs Polygons

[Martin Koppenhoefer]

sent from a phone

> On 22. Apr 2020, at 07:51, John Willis via Tagging 
>  wrote:
> 
> -1  I really like tagging info onto landuses and buildings because that is 
> *exactly* what I’m trying to convey - everything in this area or building is 
> *this thing*


but the building is also a thing, it has its own properties, e.g. start_date, 
wikipedia reference, architect, operator, name, height, etc 

yes, often you can understand which tag belongs to which object, when several 
objects are represented by one OpenStreetMap object (and that’s why we tolerate 
this kind of representation), but strictly, you can’t even know whether the 
name belongs to the building or to the occupant (it “works” because you assume 
that buildings mostly don’t have names).

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

Re: [Tagging] Points vs Polygons

[John Willis via Tagging]

> On Apr 20, 2020, at 7:22 AM, Joseph Eisenberg  
> wrote:
> 
>> we end up with most POIs [e.g. shops] added as nodes, as it appears to be 
>> currently the best compromise in terms of mapping efficiency, accuracy, 
>> complexity and editability.
> 
> +1

+1 as well, but I do not want this to become a standard way to map all POIs 
that resemble businesses. 



> 
>> I know there are lots of building=yes with POI data added, but I would 
>> discourage this because there really is no way to tell which of the 
>> properties (e.g. name) belongs to the building and which to the business.
> 
> +1

-1  I really like tagging info onto landuses and buildings because that is 
*exactly* what I’m trying to convey - everything in this area or building is 
*this thing*


It should be said to use the *proper* method, which may be pins most of the 
time, but for more complicated mappings, all might be used. 

This is especially true with modern indoor malls - where you are going to see a 
lot of shop mapping. This nesting becomes vitally important. 

The “mall” is the retail landuse. the named parking lots, the access roads, the 
mall buildings, the satellite buildings - that is “the mall”. 

The mall is often times a collection of many buildings. Anchor stores often 
take a whole building with additional small shops inside, or the buildings 
themselves have names (center mall, south mall) stuffed with many small shops. 

https://www.openstreetmap.org/#map=17/36.29322/139.39888 



In my example, Aeon Mall Ota is the entire place. There is an anchor department 
store - Aeon - on the north end. the mall is then two adjoined buildings - the 
center mall and south mall. (the mall was lengthened and the segments named 
differently). 

then, inside those buildings, are all the POI’s of the different shops, 
restaurants, amenities, and so forth. 

In this case, the info for the mall is on the landuse (it is the whole landuse).

the info for Aeon shop is on the building. (it is the entire building, and 
named for it). 

The info of the general mall shops are on pins (as they take up suites) 


This is a MASSIVELY USEFUL ability to nest different POIs on top of each other. 
Similar to other situations, being able to specify points for shops inside a 
larger land area is useful. 

Javbw


 

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

Re: [Tagging] Points vs Polygons

[Joseph Eisenberg]

> we end up with most POIs [e.g. shops] added as nodes, as it appears to be 
> currently the best compromise in terms of mapping efficiency, accuracy, 
> complexity and editability.

+1

> I know there are lots of building=yes with POI data added, but I would 
> discourage this because there really is no way to tell which of the 
> properties (e.g. name) belongs to the building and which to the business.

+1

-- Joseph Eisenberg

On 4/20/20, Tobias Knerr  wrote:
> On 19.04.20 20:33, Paul Allen wrote:
>> On Sun, 19 Apr 2020 at 19:29, Justin Tracey > > wrote:
>>
>> Another major exceptions where mapping as an internal node is
>> better, IME, are notable (historical) buildings that currently house
>> a business. More generally, if the tags of the building and business
>> would conflict (e.g., name), then it makes sense to keep them as
>> separate features.
>>
>>
>> If the building's name is still used as the house name, that's not a
>> problem. Otherwise old_name=* takes care of it.
>
> Not in the general case (the name may continue to be in use, but not as
> part of the address). And there are other tags which may warrant a
> distinction between the building and the business, such as start_date.
>
> I would say the cleanest way to solve this, where necessary, is by
> creating separate features for the business and the building. Separate
> features don't have to mean a node for the business, it can mean two
> polygons.
>
> Of course, that's more work than either of the two popular shortcuts, so
> these still have their place. But polygons for businesses work no matter
> whether there's multiple tenants or just one, and it even works for
> indoor maps and other micromapping use cases.
>
> Tobias
>
> ___
> 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] Points vs Polygons

[Tobias Knerr]

On 19.04.20 20:33, Paul Allen wrote:
> On Sun, 19 Apr 2020 at 19:29, Justin Tracey  > wrote:
> 
> Another major exceptions where mapping as an internal node is
> better, IME, are notable (historical) buildings that currently house
> a business. More generally, if the tags of the building and business
> would conflict (e.g., name), then it makes sense to keep them as
> separate features.
> 
> 
> If the building's name is still used as the house name, that's not a
> problem. Otherwise old_name=* takes care of it.

Not in the general case (the name may continue to be in use, but not as
part of the address). And there are other tags which may warrant a
distinction between the building and the business, such as start_date.

I would say the cleanest way to solve this, where necessary, is by
creating separate features for the business and the building. Separate
features don't have to mean a node for the business, it can mean two
polygons.

Of course, that's more work than either of the two popular shortcuts, so
these still have their place. But polygons for businesses work no matter
whether there's multiple tenants or just one, and it even works for
indoor maps and other micromapping use cases.

Tobias

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

Re: [Tagging] Points vs Polygons

[Martin Koppenhoefer]

sent from a phone

> On 19. Apr 2020, at 20:29, Justin Tracey  wrote:
> 
> Another major exceptions where mapping as an internal node is better, IME, 
> are notable (historical) buildings that currently house a business. More 
> generally, if the tags of the building and business would conflict (e.g., 
> name), then it makes sense to keep them as separate features.


sure, using an area did not imply mixing business tags with buildings, even if 
the business occupies the whole footprint.

While you could redraw the same geometry over the building (not 100,0% accurate 
because buildings get drawn on their outline, while businesses would in theory 
be drawn at the inside, but actually not even with the established indoor 
tagging scheme you would draw wall widths), I find these troublesome to edit. 
The alternative are multipolygons where you reuse the building geometry as 
outer member (usually the only multipolygon member in these cases). They might 
seem overkill on the other hand, and make editing harder for inexperienced 
mappers.

So basically we end up with most pois added as nodes, as it appears to be 
currently the best compromise in terms of mapping efficiency, accuracy, 
complexity and editability.

I know there are lots of building=yes with poi data added, but I would 
discourage this because there really is no way to tell which of the properties 
(e.g. name) belongs to the building and which to the business.

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

Re: [Tagging] Points vs Polygons

[Tobias Knerr]

On 19.04.20 19:51, Shawn K. Quinn wrote:
> I have noticed an issue putting things like the address on large
> buildings. Sometimes software that generates routings (OsmAnd) doesn't
> handle it gracefully and routes you to the wrong place.

My preferred way to handle this is to tag a node of the building polygon
as entrance=yes or entrance=main to mark the location of the entrance.
This allows routing software to know where it should guide you.

(Whether any given routing software already supports this is a different
story, of course, but at over 2 million uses this is a thoroughly
established tagging practice.)

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

Re: [Tagging] Points vs Polygons

[Paul Allen]

On Sun, 19 Apr 2020 at 19:29, Justin Tracey  wrote:

> Another major exceptions where mapping as an internal node is better, IME,
> are notable (historical) buildings that currently house a business. More
> generally, if the tags of the building and business would conflict (e.g.,
> name), then it makes sense to keep them as separate features.
>

If the building's name is still used as the house name, that's not a
problem.  Otherwise
old_name=* takes care of it.

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

Re: [Tagging] Points vs Polygons

[Paul Allen]

On Sun, 19 Apr 2020 at 18:53, Shawn K. Quinn  wrote:

Other than that, I generally agree with putting info on smaller
> one-tenant building outlines versus adding a separate node.
>

Disadvantage of node: you have to duplicate the address.  You need the
address on the business so Nominatim doesn't return multiple results in
the same general area that you cannot distinguish between.  But the
address includes the house number or name so you need the address
on that, too.  This goes against the principle "Don't repeat yourself."

Disadvantage of area (I've really seen people argue this): the shop is only
the part where customers go, not the storage areas or living space.  So
the shop should not be contiguous with the building.

There are no right answers, just answers of varying degrees of wrongness.

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

Re: [Tagging] Points vs Polygons

[Justin Tracey]

Another major exceptions where mapping as an internal node is better, IME,
are notable (historical) buildings that currently house a business. More
generally, if the tags of the building and business would conflict (e.g.,
name), then it makes sense to keep them as separate features.

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

Re: [Tagging] Points vs Polygons

[Shawn K. Quinn]

On 4/19/20 12:46, Martin Koppenhoefer wrote:
> Generally, polygons are superior to nodes and should not be "converted"
> to nodes, while converting nodes to polygons seems [ad]vantageous.

I have noticed an issue putting things like the address on large
buildings. Sometimes software that generates routings (OsmAnd) doesn't
handle it gracefully and routes you to the wrong place.

Other than that, I generally agree with putting info on smaller
one-tenant building outlines versus adding a separate node.

-- 
Shawn K. Quinn 
http://www.rantroulette.com
http://www.skqrecordquest.com

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

Re: [Tagging] Points vs Polygons

[Martin Koppenhoefer]

vantageous.


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

Re: [Tagging] Points vs Polygons

[Martin Koppenhoefer]

Am So., 19. Apr. 2020 um 17:53 Uhr schrieb Robert Castle <
castler...@gmail.com>:

> I noticed that some businesses are polygons whereas others are points
> within a polygon. I was wondering which way is correct.
>


both is correct, although they are not equal. With polygons, you also
convey information about size, shape and orientation, while with
nodes/points, you only give information about the position.

As adding a shape for every small business is a lot of work, and it doesn't
change much in practical terms because they are all more of less of the
"expected" size for a small business, many such objects are mapped only as
nodes. The bigger the thing gets, the more interesting it becomes to add it
as a polygon, usually.

Generally, polygons are superior to nodes and should not be "converted" to
nodes, while converting nodes to polygons seems vantageous.

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

Re: [Tagging] Points vs Polygons

[Clifford Snow]

Rob,
First welcome to OSM.

When adding businesses, I use the convention that if the building holds
multiple businesses, then each business is a separate node. If the building
only holds on business, then I typically add the business information to
the building polygon. Like a McDonalds fast food restaurant. However, there
is nothing wrong with using nodes even though it's the only business.

For those buildings that hold a number of businesses, adding addr:unit is
very helpful.

If you need more information let me know.

Best,
Clifford

On Sun, Apr 19, 2020 at 8:52 AM Robert Castle  wrote:

> Hi Everyone,
>
> I'm new to OSM and have been I've been making some edits on Main Street
> of my hometown. All the buildings seem to have been mapped, but many of the
> businesses are not mapped or have incomplete information, so I've been
> adding in the business names that aren't there and editing the ones that
> have incomplete info. I noticed that some businesses are polygons whereas
> others are points within a polygon. I was wondering which way is correct.
>
> Best,
> Rob
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
@osm_washington
www.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Points vs Polygons

[Robert Castle]

Hi Everyone,

I'm new to OSM and have been I've been making some edits on Main Street of
my hometown. All the buildings seem to have been mapped, but many of the
businesses are not mapped or have incomplete information, so I've been
adding in the business names that aren't there and editing the ones that
have incomplete info. I noticed that some businesses are polygons whereas
others are points within a polygon. I was wondering which way is correct.

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