Re: [Talk-us] Tagging outdoor US shopping centers
On Tue, Dec 23, 2014 at 7:17 PM, Tod Fitch wrote: > I am more likely to use your option 1: Each shopping center a separate > landuse=retail, name=* covering the entire area including parking but not > the land associated with the roadway right of way. As an example there are > two named shopping centers at this intersection: > http://www.openstreetmap.org/#map=18/37.36843/-122.03593 Yes, I agree that you don't want to connect the landuse polygons to the adjacent roads. Two adjacent landuse polygons can share nodes if there's nothing between them. Generally, you have the Way objects for the roads in the center of the road and the landuse for the shopping center starts once you get off the road and onto the property for the shopping center. landuse=retail is for primarily stores and restaurants and landuse=commercial is primarily for things like doctors' offices. Using landuse=retail for the shopping center is a great place to also put the name tag. You can have smaller landuse polygons that are inside of larger "broad brush" ones. Many of these have websites which you can add using the website tag as well. I also use landuse=residential to put a name tag on a named residential housing division. I prefer to split up the larger buildings for each store rather than just drawing a big building polygon and putting nodes in for the stores. See the buildings within the following example: http://www.openstreetmap.org/way/178251857 --Peter ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Tagging outdoor US shopping centers
I am more likely to use your option 1: Each shopping center a separate landuse=retail, name=* covering the entire area including parking but not the land associated with the roadway right of way. As an example there are two named shopping centers at this intersection: http://www.openstreetmap.org/#map=18/37.36843/-122.03593 I would really avoid using locality=* as I associate using that for a populated place. I think that relations could work in theory but it seems that they are poorly supported/understood by the average editor/mapper and the complexity is not needed to capture the information. Not sure what your item 2 was going to be. :) Cheers Tod On Dec 23, 2014, at 6:40 PM, Doug Hembry wrote: > I'm a relative newbie, and here's a question I've been puzzling over for a > while: What's the best practice for tagging a north American outdoor shopping > center? For example, often, on an intersection between major suburban > streets, there are collections of stores, in one or multiple buildings, > grouped around one or more shared car parks. And they have names > ("Cornerstone", "Kings Court",... or whatever). Sometimes there are four > groups of stores, one on each quadrant of the intersection, with four > different names. In the past, someone may have tagged the whole general area > with landuse=retail (or landuse=commercial - not sure why the difference), > but the map doesn't know of, nor display, the distinct identities (which > are frequently used locally in ads, etc). How to incorporate these distinct > names, and if possible have mapnik display something? I have considered or > seen several ways: > > 1. Split a big generic landuse=retail area into multiple smaller > landuse=retail polygons, one for each shopping area. Then there are issues > about whether adjacent areas should share boundary nodes with each other, or > with separating roads. It gets complicated, and tedious to implement. > > 3. I've seen place=locality used on a single node with a name=*. It displays, > but place=locality is supposed to describe an uninhabited region, according > to the wiki. > > 4. Is this a legitimate use of the site relation? Buildings, shops, car park > areas, gas stations, etc, could be grouped together and named, perhaps with a > label tag, and no explicit boundary way required. The boundary of a shopping > center is usually fairly obvious when viewing the map - a drawn boundary > might not be considered essential. This is attractive, but are site relations > approved at this point, and will Mapnik display their names (I know... don't > map for the renderer...)? Plus, I've never seen this used. > > Breaking up a big landuse=retail area seems clumsy and problematic. And I > suspect the usage of landuse=retail is supposed to be a generic, "broad > brush" classification of a whole region rather than a way of identifying > smallish distinct contiguous areas, identical except for their names. What I > think I need is a shop=shopping_center tag (or shopping_centre, if our > European colleagues insist :) ), applied to either a strategically placed > node or a newly defined boundary way. But it doesn't exist, strangely. Note > that shop=mall isn't right, because malls are explicitly indoors. Maybe it's > only here in California, where it never rains ( dark humor. At least until > very recently) that we have this phenomenon of outdoor shoping areas, but I > don't think so. Note also that single isolated shopping areas are not a > problem - the landuse=retail area can simply be given a name=* tag. But for > the more complicated cases - any suggestions? > smime.p7s Description: S/MIME cryptographic signature ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Tagging outdoor US shopping centers
I'm a relative newbie, and here's a question I've been puzzling over for a while: What's the best practice for tagging a north American outdoor shopping center? For example, often, on an intersection between major suburban streets, there are collections of stores, in one or multiple buildings, grouped around one or more shared car parks. And they have names ("Cornerstone", "Kings Court",... or whatever). Sometimes there are four groups of stores, one on each quadrant of the intersection, with four different names. In the past, someone may have tagged the whole general area with landuse=retail (or landuse=commercial - not sure why the difference), but the map doesn't know of, nor display, the distinct identities (which are frequently used locally in ads, etc). How to incorporate these distinct names, and if possible have mapnik display something? I have considered or seen several ways: 1. Split a big generic landuse=retail area into multiple smaller landuse=retail polygons, one for each shopping area. Then there are issues about whether adjacent areas should share boundary nodes with each other, or with separating roads. It gets complicated, and tedious to implement. 3. I've seen place=locality used on a single node with a name=*. It displays, but place=locality is supposed to describe an uninhabited region, according to the wiki. 4. Is this a legitimate use of the site relation? Buildings, shops, car park areas, gas stations, etc, could be grouped together and named, perhaps with a label tag, and no explicit boundary way required. The boundary of a shopping center is usually fairly obvious when viewing the map - a drawn boundary might not be considered essential. This is attractive, but are site relations approved at this point, and will Mapnik display their names (I know... don't map for the renderer...)? Plus, I've never seen this used. Breaking up a big landuse=retail area seems clumsy and problematic. And I suspect the usage of landuse=retail is supposed to be a generic, "broad brush" classification of a whole region rather than a way of identifying smallish distinct contiguous areas, identical except for their names. What I think I need is a shop=shopping_center tag (or shopping_centre, if our European colleagues insist :) ), applied to either a strategically placed node or a newly defined boundary way. But it doesn't exist, strangely. Note that shop=mall isn't right, because malls are explicitly indoors. Maybe it's only here in California, where it never rains ( dark humor. At least until very recently) that we have this phenomenon of outdoor shoping areas, but I don't think so. Note also that single isolated shopping areas are not a problem - the landuse=retail area can simply be given a name=* tag. But for the more complicated cases - any suggestions? ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us