[Tagging] Feature Proposal - RFC - area:highway
it has been brought up a couple of times in the german forums, so it seems there is a need for mapping the dimensions of roads (similar to riverbanks for rivers). the tag itself was suggested by another user, but i thought it would be a good idea to put it into a dedicated proposal. http://wiki.openstreetmap.org/wiki/Proposed_features/area:highway flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tags for neighborhoods / subdivisions
2011/5/11 Josh Doe :
> It's been about a month now, and I've gotten some feedback from the
> talk page. My thoughts are that we either:
>
> * reuse the existing place=suburb (as the wiki definition seems like
> it might work)
> * use the new place=neighbourhood
yes, you can use suburb for all kinds of subdivisions, but it is not
really helpful for other then find something for a given name. In the
case of an actual hierarchy ("is contained in") or a quantitative
distinction ([neighbour hood] "is smaller then" [suburb]) it would be
desirable to have this relation in the database as well. So
place=neighbourhood would be preferable to suburb for mapping
neighbourhoods.
> Either way I think we need to allow for admin_level or something
> similar to permit nesting of neighborhoods. Any more feedback is
> appreciated, particularly in regards to this latter point regarding
> nesting.
Yes, I also would like to have an approach to do nested hierarchies as
well as parallel systems for "sub-settlement places". In Rome there is
at least 4 different systems of toponyms/subdivisions (plus other
toponyms for various places), which apparently sometimes do overlap or
not, and are there for historic reasons besides the actual current
administrational divisions. I feel that mapping all of them with
different place values does seem reasonable.
To give you an idea this is an overview in Italian:
http://it.wikipedia.org/wiki/Suddivisioni_di_Roma (the English
version concentrates on administration and is leaving out a lot of
aspects). We already talked about this locally, but did not yet move
towards a proposal.
cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tags for neighborhoods / subdivisions
On 11/05/2011 05:27, Josh Doe wrote: It's been about a month now, and I've gotten some feedback from the talk page. My thoughts are that we either: * reuse the existing place=suburb (as the wiki definition seems like it might work) * use the new place=neighbourhood Either way I think we need to allow for admin_level or something similar to permit nesting of neighborhoods. Any more feedback is appreciated, particularly in regards to this latter point regarding nesting. -Josh I would recommend maintaining clarity as to whether an admin_level is *official (as opposed to informal) *strictly hierarchical (as opposed to geographic/topographic areas) For example, "London" in an informal sense will probably not correspond to the area governed by the "Greater London Authority" and will overlap with other local government areas. With "neighbourhoods" and "suburbs" which are frequently "informally" defined, the admin_level does not imply a particular position in a particular hierarchy, but would simply be a way of selecting boundaries of a given type. In this case the actual value doesn't matter so much, as long as it is unique. In the strict hierarchy of local government, the value does matter as an area of admin_level N will be contained within an area of admin_level (N-1). Of course there can also be parallel hierarchies, like police force areas and their districts and subdistricts, or postal systems with major towns, distribution points and individual postcodes (in the UK these frequently span national borders!). Colin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tags for neighborhoods / subdivisions
2011/5/11 Colin Smale : > Of course there can also be parallel > hierarchies, like police force areas and their districts and subdistricts, > or postal systems with major towns, distribution points and individual > postcodes (in the UK these frequently span national borders!). +1, also think about the organisation and subdivisions of the catholic church, which is strictly hierarchical and spans over huge parts of the world down to very fine granular divisions. Has anyone ever tried to get this info? Maybe the vatican has this stuff in a GIS form and would donate the data? Is there any interest? cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - area:highway
On 5/11/2011 5:09 AM, Flaimo wrote: it has been brought up a couple of times in the german forums, so it seems there is a need for mapping the dimensions of roads (similar to riverbanks for rivers). the tag itself was suggested by another user, but i thought it would be a good idea to put it into a dedicated proposal. http://wiki.openstreetmap.org/wiki/Proposed_features/area:highway There's a problem if this is treated like landuse. The highway landuse goes up to the edge of the right-of-way, and includes sidewalks and and clear zones, but your example includes only the paved driving area. This is more of a surface tag, like a pond in a park or a sand trap in a golf course. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Requirements for proposals and voting to be valid
Hi. Right now I've had a wtf moment. As some of you remember, there was a proposal for water=* tag. It was discussed, voted upon and approved by 16 to 3 votes. But now there are some enraged wiki editors, one of whom erased the whole voting section and reverted status to "Proposed". And the reasons, which he stated in the discussion page, were those: > The procedure for a vote on Proposed_features#Voting requires a specific Subject line > in the e-mail sent to the tagging list. As this was not used, the vote is invalid. > I will remove the vote on this page and leave someone to reopen it correctly > if they really think this is a good idea. I've reverted his edits of the proposal page, but is he right? Is any proposal with incorrect subject line in tagging@ post (let along those which weren't mentioned here) automatically invalid? IZ ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - area:highway
2011/5/11 Nathan Edgars II : > There's a problem if this is treated like landuse. it is not "landuse", so there is no problem. There is still space for landuse=highway. > The highway landuse goes > up to the edge of the right-of-way, and includes sidewalks and and clear > zones, but your example includes only the paved driving area. This is more > of a surface tag, like a pond in a park or a sand trap in a golf course. +1 I think that area:highway is fine for the key name. There is some other problems (or better missed opportunities) in this proposal. See the discussion page. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Requirements for proposals and voting to be valid
On 11/05/2011 12:19, Ilya Zverev wrote: I've reverted his edits of the proposal page, but is he right? Is any proposal with incorrect subject line in tagging@ post (let along those which weren't mentioned here) automatically invalid? If so most of map features would be "invalid" because many features there predate the tagging@ list. The problem is that there are many different versions of "valid" in the OSM world: "valid" in the wiki just means that people who read the wiki and can be bothered to vote thought that it was a good idea. "valid" on the map means actually used lots of times "valid" in the editors means that the editor authors thought that a particular combination was relevant to that editor's target mark "valid" in the renderers means something different again, etc. So it seems to me like a valid wiki vote. As to what relevance it has elsewhere? Not so sure. Cheers, Andy ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - area:highway
On 5/11/2011 7:34 AM, M∡rtin Koppenhoefer wrote: 2011/5/11 Nathan Edgars II: There's a problem if this is treated like landuse. it is not "landuse", so there is no problem. There is still space for landuse=highway. The proposal makes reference to landuse, in particular stating that one might cut off adjacent landuses at its border. But the two positions on landuse are that it shouldn't be cut or that it should be cut at the right-of-way line, not at the edge of the roadway. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Requirements for proposals and voting to be valid
2011/5/11 Ilya Zverev : > I've reverted his edits of the proposal page, but is he right? Is any > proposal with incorrect subject line in tagging@ post (let along those > which weren't mentioned here) automatically invalid? Well, it is an established convention to send an email to tagging with "VOTING" in the subject, but I would not go so far to consider the voting "invalid" if this did not happen. IMHO you did right to revert his fiddling. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - area:highway
2011/5/11 Nathan Edgars II : > The proposal makes reference to landuse, in particular stating that one > might cut off adjacent landuses at its border. But the two positions on > landuse are that it shouldn't be cut or that it should be cut at the > right-of-way line, not at the edge of the roadway. +1, you're right I overlooked this. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Requirements for proposals and voting to be valid
On 11/05/11 12:38, SomeoneElse wrote: On 11/05/2011 12:19, Ilya Zverev wrote: I've reverted his edits of the proposal page, but is he right? Is any proposal with incorrect subject line in tagging@ post (let along those which weren't mentioned here) automatically invalid? If so most of map features would be "invalid" because many features there predate the tagging@ list. The problem is that there are many different versions of "valid" in the OSM world: "valid" in the wiki just means that people who read the wiki and can be bothered to vote thought that it was a good idea. "valid" on the map means actually used lots of times "valid" in the editors means that the editor authors thought that a particular combination was relevant to that editor's target mark "valid" in the renderers means something different again, etc. And "valid" on the wiki is the least significant of these. The wiki should be a place to document the various parts of OSM, and for things like software it can be useful. For tags, however, it is getting steadily more and more complex and confusing and less and less beneficial. I would suggest to the wiki fiddlers out there dreaming up their latest proposal: each actual use of the new tags you propose entitles you to write one word in the proposal. I know this may sound odd to some: i.e use a tag *before* the proposal is written, but that will make your proposal grounded in reality not the pie-in-the-sky rubbish we sometimes, and increasingly often, see. -- Cheers, Chris user: chillly ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Requirements for proposals and voting to be valid
On Wed, May 11, 2011 at 1:52 PM, Chris Hill wrote: > The wiki should be a place to document the various parts of OSM, and for > things like software it can be useful. For tags, however, it is getting > steadily more and more complex and confusing and less and less beneficial. I think we need to set a wiki principle: it should be descriptive. If there are different views then we should describe them, with an objective indication of relative popularity. Deleting someone's views because you disagree is vandalism. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Requirements for proposals and voting to be valid
Am 11.05.2011 15:04, schrieb Richard Mann: > On Wed, May 11, 2011 at 1:52 PM, Chris Hill wrote: >> The wiki should be a place to document the various parts of OSM, and for >> things like software it can be useful. For tags, however, it is getting >> steadily more and more complex and confusing and less and less beneficial. > > I think we need to set a wiki principle: it should be descriptive. If > there are different views then we should describe them, with an > objective indication of relative popularity. Deleting someone's views > because you disagree is vandalism. +1 >> >> I would suggest to the wiki fiddlers out there dreaming up their latest >> proposal: each actual use of the new tags you propose entitles you to >> write one word in the proposal. I know this may sound odd to some: i.e >> use a tag *before* the proposal is written, but that will make your >> proposal grounded in reality not the pie-in-the-sky rubbish we >> sometimes, and increasingly often, see. You can make a proposal, leave it in proposal state and just start tagging, without any vote. If it is a good proposal other users will use it and it will get accepted without any vote. The big advantage is that the discussion can be longer than just a few weeks, with possibility to still change the proposal and you will get examples to demonstrate and maybe also find some problems. cu fly ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Requirements for proposals and voting to be valid
On 11 May 2011 23:04, Richard Mann wrote: > On Wed, May 11, 2011 at 1:52 PM, Chris Hill wrote: >> The wiki should be a place to document the various parts of OSM, and for >> things like software it can be useful. For tags, however, it is getting >> steadily more and more complex and confusing and less and less beneficial. > > I think we need to set a wiki principle: it should be descriptive. If > there are different views then we should describe them, with an > objective indication of relative popularity. Deleting someone's views > because you disagree is vandalism. +1 Regardless what the object of interest people want to tag, people are going to tag something if it is of enough importance to them, and we should be describing things on the wiki so that we don't end up with 10 different ways to tag the same thing. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - area:highway
you misread that. because if its imprecise definition, there are still heated discussions on how detailed landuses should be mapped. some leave out the areas of the streets, some don't. all i wanted to state out is, that this isn't a part of the area:highway proposal. if you want to draw it over landuses you can do so, but if you are part of the other fraction you can connect it to landuses. I'm not taking sides with this proposal. flaimo > Message: 7 > Date: Wed, 11 May 2011 13:58:45 +0200 > From: M?rtin Koppenhoefer > To: "Tag discussion, strategy and related tools" > > Subject: Re: [Tagging] Feature Proposal - RFC - area:highway > Message-ID: > Content-Type: text/plain; charset=UTF-8 > > 2011/5/11 Nathan Edgars II : >> The proposal makes reference to landuse, in particular stating that one >> might cut off adjacent landuses at its border. But the two positions on >> landuse are that it shouldn't be cut or that it should be cut at the >> right-of-way line, not at the edge of the roadway. > > > +1, you're right > I overlooked this. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - area:highway
On 5/11/2011 10:47 AM, Flaimo wrote: you misread that. because if its imprecise definition, there are still heated discussions on how detailed landuses should be mapped. some leave out the areas of the streets, some don't. all i wanted to state out is, that this isn't a part of the area:highway proposal. if you want to draw it over landuses you can do so, but if you are part of the other fraction you can connect it to landuses. I'm not taking sides with this proposal. But does anyone stop the landuse at the edge of the main roadway, including the sidewalks within it? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - area:highway
2011/5/11 Nathan Edgars II > On 5/11/2011 10:47 AM, Flaimo wrote: > >> you misread that. because if its imprecise definition, there are still >> heated discussions on how detailed landuses should be mapped. some >> leave out the areas of the streets, some don't. all i wanted to state >> out is, that this isn't a part of the area:highway proposal. if you >> want to draw it over landuses you can do so, but if you are part of >> the other fraction you can connect it to landuses. I'm not taking >> sides with this proposal. >> > > But does anyone stop the landuse at the edge of the main roadway, including > the sidewalks within it? I do. My residential, industrial and farm landuses are outlined by the sidewalks or by the road. I know other mappers do this too, and they usually exclude sidewalks too. Regards, Simone ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - area:highway
On 5/11/2011 11:15 AM, Simone Saviolo wrote: 2011/5/11 Nathan Edgars II mailto:nerou...@gmail.com>> On 5/11/2011 10:47 AM, Flaimo wrote: you misread that. because if its imprecise definition, there are still heated discussions on how detailed landuses should be mapped. some leave out the areas of the streets, some don't. all i wanted to state out is, that this isn't a part of the area:highway proposal. if you want to draw it over landuses you can do so, but if you are part of the other fraction you can connect it to landuses. I'm not taking sides with this proposal. But does anyone stop the landuse at the edge of the main roadway, including the sidewalks within it? I do. My residential, industrial and farm landuses are outlined by the sidewalks or by the road. I know other mappers do this too, and they usually exclude sidewalks too. Wait, so you include sidewalks in the landuse but exclude the main roadway? That's what I asked. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tags for neighborhoods / subdivisions
On Wed, May 11, 2011 at 5:26 AM, M∡rtin Koppenhoefer
wrote:
> yes, you can use suburb for all kinds of subdivisions, but it is not
> really helpful for other then find something for a given name. In the
> case of an actual hierarchy ("is contained in") or a quantitative
> distinction ([neighbour hood] "is smaller then" [suburb]) it would be
> desirable to have this relation in the database as well. So
> place=neighbourhood would be preferable to suburb for mapping
> neighbourhoods.
I'm tending more and more to think we need place=neighbourhood,
especially since suburb is such a misnomer as it's used in OSM.
> Yes, I also would like to have an approach to do nested hierarchies as
> well as parallel systems for "sub-settlement places". In Rome there is
> at least 4 different systems of toponyms/subdivisions (plus other
> toponyms for various places), which apparently sometimes do overlap or
> not, and are there for historic reasons besides the actual current
> administrational divisions. I feel that mapping all of them with
> different place values does seem reasonable.
>
> To give you an idea this is an overview in Italian:
> http://it.wikipedia.org/wiki/Suddivisioni_di_Roma (the English
> version concentrates on administration and is leaving out a lot of
> aspects). We already talked about this locally, but did not yet move
> towards a proposal.
That's certainly more complicated than anything I'll need to use, so a
solution for that should work for my situation.
-Josh
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - area:highway
2011/5/11 Nathan Edgars II > On 5/11/2011 11:15 AM, Simone Saviolo wrote: > >> 2011/5/11 Nathan Edgars II mailto:nerou...@gmail.com >> >> >> >> >>On 5/11/2011 10:47 AM, Flaimo wrote: >> >>you misread that. because if its imprecise definition, there are >>still >>heated discussions on how detailed landuses should be mapped. some >>leave out the areas of the streets, some don't. all i wanted to >>state >>out is, that this isn't a part of the area:highway proposal. if you >>want to draw it over landuses you can do so, but if you are part of >>the other fraction you can connect it to landuses. I'm not taking >>sides with this proposal. >> >> >>But does anyone stop the landuse at the edge of the main roadway, >>including the sidewalks within it? >> >> >> I do. My residential, industrial and farm landuses are outlined by the >> sidewalks or by the road. I know other mappers do this too, and they >> usually exclude sidewalks too. >> > > Wait, so you include sidewalks in the landuse but exclude the main roadway? > That's what I asked. No, wait. I put landuse up to the border of the "property", let's say up to the fence; then there (may be) the sidewalk; then there's the road (I know that "road" legally includes the sidewalks too; I'm using it here with the commonly used meaning). The residential, industrial, whatever landuse stops before the sidewalk: the sidewalk is NOT part of a residential landuse, for instance. I understand it's debatable whether to include the sidewalk into the area:highway object. I think it should ideally be given a different object. If we agree that sidewalks should be mapped as linear highway=footway (I know there's discussion on this point, I'm making a supposition), then we should have two different area features (or multipolys or whatever), one with area:highway=unclassified/residential/whatever and another one with area:highway=footway. In simpler terms, I wouldn't use area:highway to cover the whole right-of-way area. Ciao, Simone ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - area:highway
On 5/11/2011 11:36 AM, Simone Saviolo wrote: No, wait. I put landuse up to the border of the "property", let's say up to the fence; then there (may be) the sidewalk; then there's the road (I know that "road" legally includes the sidewalks too; I'm using it here with the commonly used meaning). The residential, industrial, whatever landuse stops before the sidewalk: the sidewalk is NOT part of a residential landuse, for instance. OK, that's what I thought. Unless there is someone who puts the sidewalk inside the landuse, there's no point in mentioning landuse in this proposal. (By the way, I go up to the property line too in those cases where the landuse changes at the road. If the landuse is the same on both sides, I'll include the road in the landuse polygon, however.) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Requirements for proposals and voting to be valid
Ilya Zverev wrote: > As some of you remember, there was a > proposal for water=* tag. It was discussed, voted upon and approved by 16 > to 3 votes. But now there are some enraged wiki editors, one of whom erased > the whole voting section and reverted status to "Proposed". And the > reasons, which he stated in the discussion page, were those: > >> The procedure for a vote on Proposed_features#Voting requires a specific >> Subject line in the e-mail sent to the tagging list. He is basically right - it's important that everyone who might be interested has a chance to learn of the proposal without following all discussions. What you should do: Extend the voting period by two weeks (leaving the existing votes intact, of course), send out a mail with the correct subject, and wait what happens. As you can already use the tags without an accepted proposal, that additional two weeks period will not cause any harm, and can eliminate any doubts about the validity of the proposal. -- Tobias Knerr ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tags for neighborhoods / subdivisions
On Wed, May 11, 2011 at 6:08 AM, Colin Smale wrote: > I would recommend maintaining clarity as to whether an admin_level is > * official (as opposed to informal) > * strictly hierarchical (as opposed to geographic/topographic areas) > > For example, "London" in an informal sense will probably not correspond to > the area governed by the "Greater London Authority" and will overlap with > other local government areas. With "neighbourhoods" and "suburbs" which are > frequently "informally" defined, the admin_level does not imply a particular > position in a particular hierarchy, but would simply be a way of selecting > boundaries of a given type. In this case the actual value doesn't matter so > much, as long as it is unique. But sometimes they are formal, either at the governmental level or semi-governmental level (think HOA that has legal rights to enforce . In my area we have neighborhoods which are well defined, and even appear on county government maps. These are planned subdivisions which were created in the past thirty years or so. For my area, the hierarchy would go: Martins Landing (a Cluster in local HOA terms, a subdivision in county terms, a hundred or so homes with a sign at the entrance, I'd consider a place=neighbourhood) The Landings (a Neighborhood in local HOA terms, just a bigger place=neighbourhood) Burke Centre (the rather large HOA, which again I'd call a place=neighbourhood, also a census-designated place) Burke (a CDP, no government, but the "city" used for mailing addresses, a place=locality and admin_level=8) Fairfax County (border_type=county, admin_level=6) Virginia (admin_level=4) For my area I would mark Burke Centre as admin_level=9, The Landings as 10, and Martins Landing as 11, though this would of course vary from country to country and even state to state. As for whether to use admin_level or some other *_level key, I think there shouldn't be a problem to use/abuse the former. For my area, Burke has an admin_level=8. Burke is a census- designated place (determined by the United States Census Bureau largely for statistical purposes), and an unincorporated community recognized by the United States Postal Service for mail delivery purposes. However we have no local government. Burke Centre is also a CDP, and while it is not recognized by the USPS, it along with Martins Landing are shown on county maps. Therefore I feel that admin_level=* should be applicable at least in my case. -Josh ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - area:highway
Flaimo wrote: > it has been brought up a couple of times in the german forums, so it > seems there is a need for mapping the dimensions of roads (similar to > riverbanks for rivers). the tag itself was suggested by another user, > but i thought it would be a good idea to put it into a dedicated > proposal. I agree with the idea of using a tag like area:highway=* on areas that are mapped in addition to roads, but I'm not sure whether I agree with the example image provided on the proposal page, too. In the example image, "lanes" (in this case: sidewalks) of the road that are mapped as separate ways also have their own areas. Currently, I tend to instead support one area for the entire road, containing the central highway ways and the ways for the "lanes". If you follow the convention that each way should be drawn along the center of the real-world feature, then the width of e.g. a sidewalk can still be determined at any point along the road from just the single outline area and the way position. So unless I'm mistaken, separate areas for the individual "lanes" wouldn't provide more information; they'd just add more clutter. -- Tobias Knerr ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - area:highway
On Wed, May 11, 2011 at 1:04 PM, Tobias Knerr wrote: > In the example image, "lanes" (in this case: sidewalks) of the road that > are mapped as separate ways also have their own areas. Currently, I tend > to instead support one area for the entire road, containing the central > highway ways and the ways for the "lanes". > > If you follow the convention that each way should be drawn along the > center of the real-world feature, then the width of e.g. a sidewalk can > still be determined at any point along the road from just the single > outline area and the way position. So unless I'm mistaken, separate > areas for the individual "lanes" wouldn't provide more information; > they'd just add more clutter. I think this depends on whether you adopt the "sidewalk as a separate way" method or the sidewalk=left/right/both/no method. In my area of suburbia, I'm using separate ways, so I would likewise use two separate areas. For other areas that use sidewalk=*, such as cities with "integrated" sidewalks and streets (such as Washington D.C.), it might make more sense to use a single area, depending on the local community. That being said, I don't intend to use this tagging yet. I'd be more interested in seeing an integrated method that would allow tagging not only the area of the road, but also separate lanes that allow for turning restrictions, to be used for simulation purposes as well as precise navigation. -Josh ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tags for neighborhoods / subdivisions
On 5/11/2011 12:49 PM, Josh Doe wrote: > But sometimes they are formal, either at the governmental level or > semi-governmental level (think HOA that has legal rights to enforce. It's kind of different in that the restrictions apply only to residents and their guests, not to people passing through on public roads. The average person won't care that they're leaving the area covered by "Sky Lake South Homeowner's Association, Inc." and entering the area covered by "Homeowners Association of Sky Lake South Units Six and Seven, Inc." (real example here). Burke (a CDP, no government, but the "city" used for mailing addresses, a place=locality and admin_level=8) > As for whether to use admin_level or some other *_level key, I think there shouldn't be a problem to use/abuse the former. For my area, Burke has an admin_level=8. Burke is a census- designated place (determined by the United States Census Bureau largely for statistical purposes), and an unincorporated community recognized by the United States Postal Service for mail delivery purposes. However we have no local government. Burke Centre is also a CDP, and while it is not recognized by the USPS, it along with Martins Landing are shown on county maps. Therefore I feel that admin_level=* should be applicable at least in my case. I disagree with using admin_level for CDP boundaries (or keeping them at all), unless they are actually used for other purposes. They certainly don't match USPS city names in general. In general they are just arbitrary lines drawn by the Census Bureau. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tags for neighborhoods / subdivisions
On Wed, May 11, 2011 at 1:28 PM, Nathan Edgars II wrote: > It's kind of different in that the restrictions apply only to residents and > their guests, not to people passing through on public roads. The average > person won't care that they're leaving the area covered by "Sky Lake South > Homeowner's Association, Inc." and entering the area covered by "Homeowners > Association of Sky Lake South Units Six and Seven, Inc." (real example > here). Yes it is different, however Burke Centre is a little different than other HOAs, since it's quite large at 5,700 housing units and a population of over 17,000, making it larger than many towns. The HOA also regulates businesses and schools in terms of landscaping, signage, etc. > I disagree with using admin_level for CDP boundaries (or keeping them at > all), unless they are actually used for other purposes. They certainly don't > match USPS city names in general. In general they are just arbitrary lines > drawn by the Census Bureau. I agree, but Burke Centre is definitely not just arbitrary lines drawn by others. I'm sure there are plenty of CDPs which aren't recognized in other ways, but many do align with USPS city names. That being said the main topic here is neighborhoods, which the USPS and Census Bureau typically don't recognize, but are real names associated by real people to real geographic locations, and are therefore important to map. -Josh ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tags for neighborhoods / subdivisions
On 5/11/2011 2:08 PM, Josh Doe wrote: I agree, but Burke Centre is definitely not just arbitrary lines drawn by others. I'm sure there are plenty of CDPs which aren't recognized in other ways, but many do align with USPS city names. That being said the main topic here is neighborhoods, which the USPS and Census Bureau typically don't recognize, but are real names associated by real people to real geographic locations, and are therefore important to map. I agree that they're important to map. But they're not administrative units, and shouldn't be mapped as such. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - area:highway
Josh Doe wrote: >> So unless I'm mistaken, separate >> areas for the individual "lanes" wouldn't provide more information; >> they'd just add more clutter. > > I think this depends on whether you adopt the "sidewalk as a separate > way" method or the sidewalk=left/right/both/no method. In my area of > suburbia, I'm using separate ways, so I would likewise use two > separate areas. Just because it seems intuitively consistent, or is there some practical advantage - something that can only be expressed with these separate areas? Separate sidewalk ways have advantages (you can properly connect other ways and crossings to them, you can add tags such as surface, ...), that's why I prefer them, too. Separate areas don't seem to let you express any additional information, so I currently don't see a reason to use them. In fact, I think that a /single/ area:highway=* has an additional advantage precisely if you map sidewalks and such as separate ways: it becomes more feasible for applications to find out which sidewalk ways belong to a highway because the highway and sidewalk ways are in the same area:highway=* boundary. You wouldn't need relations or other solutions to connect them. -- Tobias Knerr ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tags for neighborhoods / subdivisions
On Wed, May 11, 2011 at 2:14 PM, Nathan Edgars II wrote: > I agree that they're important to map. But they're not administrative units, > and shouldn't be mapped as such. How do you suggest doing this without breaking the way people expect a service like Nominatim to operate? You're proposing that I remove admin_level=* from Burke, but that is the "city" that everyone in Burke uses for their mailing address, and is indeed what the USPS uses. The only strict administrative unit in my area is Fairfax County, which is a place with over a million people. Whether we like it or not admin_level is used for more than just strict administrative units. We either need to admit it and keep on using it, or create something else and change the many existing uses to the new key. -Josh ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Requirements for proposals and voting to be valid
Actually there is a problem here: http://taginfo.openstreetmap.de/keys/water#values "water" is already in wide use, but most of the values in use are not part of the proposal. Maybe some amendmend or changing of the key name (e.g. water:type seems to be what the proposal wants to achieve: http://taginfo.openstreetmap.de/keys/water%3Atype#values ) would be appropriate. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - area:highway
2011/5/11 Tobias Knerr : > Flaimo wrote: > In the example image, "lanes" (in this case: sidewalks) of the road that > are mapped as separate ways also have their own areas. Currently, I tend > to instead support one area for the entire road, containing the central > highway ways and the ways for the "lanes". > > If you follow the convention that each way should be drawn along the > center of the real-world feature, then the width of e.g. a sidewalk can > still be determined at any point along the road from just the single > outline area and the way position. no, if this would be possible there would be no sense at all to map areas. You can't see sidewalks as "just another lane", because they tend to be quite irregular in certain settings (unlike lanes which usually keep their width and have no corners and other weird points). The point of mapping areas is to be able to map irregular street areas, changes in the sidewalk and similar. That's why I proposed the area relation: to be able to map these details, to be able to add topology details like kerbs and lower kerbs and similar issues. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - area:highway
that is perfectly possible with area:highway. just tag the road area:highway=residential for example and the other area:highway=footway. all values from the highway key are possible (at least from the roads or paths category). flaimo > Message: 7 > Date: Wed, 11 May 2011 17:36:04 +0200 > From: Simone Saviolo > To: "Tag discussion, strategy and related tools" > > Subject: Re: [Tagging] Feature Proposal - RFC - area:highway > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > I understand it's debatable whether to include the sidewalk into the > area:highway object. I think it should ideally be given a different object. > If we agree that sidewalks should be mapped as linear highway=footway (I > know there's discussion on this point, I'm making a supposition), then we > should have two different area features (or multipolys or whatever), one > with area:highway=unclassified/residential/whatever and another one with > area:highway=footway. In simpler terms, I wouldn't use area:highway to cover > the whole right-of-way area. > ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tags for neighborhoods / subdivisions
On 11/05/2011 20:28, Josh Doe wrote: On Wed, May 11, 2011 at 2:14 PM, Nathan Edgars II wrote: I agree that they're important to map. But they're not administrative units, and shouldn't be mapped as such. How do you suggest doing this without breaking the way people expect a service like Nominatim to operate? You're proposing that I remove admin_level=* from Burke, but that is the "city" that everyone in Burke uses for their mailing address, and is indeed what the USPS uses. The only strict administrative unit in my area is Fairfax County, which is a place with over a million people. Whether we like it or not admin_level is used for more than just strict administrative units. We either need to admit it and keep on using it, or create something else and change the many existing uses to the new key. Tagging something wilfully and deliberately wrongly in order to obtain the desired visible results is called "tagging for the renderer" and is almost universally frowned upon - see [1]... If Nominatim doesn't know to look at other objects than boundary=admin etc, then wouldn't it be better to fix Nominatim? If it's an administrative unit, give it an admin_level. If it's not, don't - let's call a spade a spade and tag it like it is. If Burke is not a City in the administrative sense, what *is* it? Which organisation decided (exactly) where the boundaries are and has the power to change them? If it's USPS, could we tag it boundary=postal_city, name=Burke, source:name=USPS? [1] http://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer Colin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - voting - childcare
there was a lot of discussion going on over the last two days for this proposal, but still hardly anyone voted. i think it would be a good idea if everyone who took part in the discussion would vote, so that we at least get an impression on the tendency for or against the childcare value. currently there are only five (positive) votes which isn't a lot. i could also live with the social_facility value in case it gets declined, but i would like to see a meaningful result in the votes. http://wiki.openstreetmap.org/wiki/Proposed_features/childcare#Voting flaimo ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tags for neighborhoods / subdivisions
On Wed, May 11, 2011 at 3:00 PM, Colin Smale wrote: > Tagging something wilfully and deliberately wrongly in order to obtain the > desired visible results is called "tagging for the renderer" and is almost > universally frowned upon - see [1]... If Nominatim doesn't know to look at > other objects than boundary=admin etc, then wouldn't it be better to fix > Nominatim? +1 - Serge ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tags for neighborhoods / subdivisions
Part of the problem is that neighborhoods, unlike official administrative units, or even Home Owner Associations, don't necessarily have agreed-upon boundaries. Different people may consider the same location to be in different neighborhoods. ---Original Email--- Subject :Re: [Tagging] Tags for neighborhoods / subdivisions >From :mailto:j...@joshdoe.com Date :Wed May 11 13:28:59 America/Chicago 2011 On Wed, May 11, 2011 at 2:14 PM, Nathan Edgars II wrote: > I agree that they're important to map. But they're not administrative units, > and shouldn't be mapped as such. How do you suggest doing this without breaking the way people expect a service like Nominatim to operate? You're proposing that I remove admin_level=* from Burke, but that is the "city" that everyone in Burke uses for their mailing address, and is indeed what the USPS uses. The only strict administrative unit in my area is Fairfax County, which is a place with over a million people. Whether we like it or not admin_level is used for more than just strict administrative units. We either need to admit it and keep on using it, or create something else and change the many existing uses to the new key. -Josh ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging Sent from my Verizon Wireless BlackBerry ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tags for neighborhoods / subdivisions
On Wed, May 11, 2011 at 3:00 PM, Colin Smale wrote: > Tagging something wilfully and deliberately wrongly in order to obtain the > desired visible results is called "tagging for the renderer" and is almost > universally frowned upon - see [1]... If Nominatim doesn't know to look at > other objects than boundary=admin etc, then wouldn't it be better to fix > Nominatim? > > If it's an administrative unit, give it an admin_level. If it's not, don't - > let's call a spade a spade and tag it like it is. If Burke is not a City in > the administrative sense, what *is* it? Which organisation decided (exactly) > where the boundaries are and has the power to change them? If it's USPS, > could we tag it boundary=postal_city, name=Burke, source:name=USPS? I'm all for creating something else, however I didn't tag it this way, this is how the TIGER places import was done, so this affects at least the entire US. At least in the US, large counties are often the lowest administrative level, however it's critical to include lower level "place" boundaries. And it's not just a matter of fixing Nominatim, we need to come up with a new admin_level like tag. Can we begin discussion of this? A "place_level" that allows for unincorporated areas, neighborhoods, and the like. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tags for neighborhoods / subdivisions
On Wed, May 11, 2011 at 3:14 PM, wrote: > Part of the problem is that neighborhoods, unlike official administrative > units, or even Home Owner Associations, don't necessarily have agreed-upon > boundaries. Different people may consider the same location to be in > different neighborhoods. I've addressed that on the wiki page. In the case of vague boundaries, simply use a node. But let me assure you that HOAs have very well defined, typically legal boundaries. -Josh ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tags for neighborhoods / subdivisions
On Wed, May 11, 2011 at 3:28 PM, Josh Doe wrote: > I'm all for creating something else, however I didn't tag it this way, > this is how the TIGER places import was done, so this affects at least > the entire US. Saying it's the way it was done in the single worst import we've done in the project doesn't help make it any more appealing. The right solution isn't to look to the US Census or other organizations, but to go back to basics and try to find a scheme that works for OSM. > Can we begin discussion of this? A "place_level" that allows for > unincorporated areas, neighborhoods, and the like. I don't think that's the right solution because that's precisely what brought about a discussion a few months back where NE2 wanted to delete Silver Spring, Bethesda, and a whole lot of other cities and towns in the US. Political boundaries aren't the most important thing, certainly they're less important than actual usage. - Serge ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - area:highway
M∡rtin Koppenhoefer wrote: >> If you follow the convention that each way should be drawn along the >> center of the real-world feature, then the width of e.g. a sidewalk can >> still be determined at any point along the road from just the single >> outline area and the way position. > > no, if this would be possible there would be no sense at all to map > areas. You can't see sidewalks as "just another lane", because they > tend to be quite irregular in certain settings (unlike lanes which > usually keep their width and have no corners and other weird points). I don't think this contradicts my argument. Look at the cross-section of the road at any point: | * . . . .* | The vertical lines are road area outlines, the stars are sidewalk ways and the dots are other "lanes". If we make the assumption that each way marks the center of that "lane", we can easily calculate the width of the two sidewalks at this particular cut through the road: It's 2 times the width between the sidewalk and the area outline. How a cross-section of a road looks will of course vary a lot along the road - lanes, including sidewalks, might change their width, disappear entirely etc. But that isn't a problem as long as you can determine the road structure at each interesting point along the road. > The point of mapping areas is to be able to map irregular street > areas, changes in the sidewalk and similar. That's why I proposed the > area relation: to be able to map these details, to be able to add > topology details like kerbs and lower kerbs and similar issues. The area relation is interesting conceptually, but it just seems so very different from the way-based modelling we currently use for roads. I don't believe it would work without a major redesign of our editing tools, and I don't see OSM as a project with enough coordination to successfully implement a major change like that if it cannot easily be broken down into small evolutionary steps. -- Tobias Knerr ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - area:highway
Am 11.05.2011 um 23:01 schrieb Tobias Knerr: > M∡rtin Koppenhoefer wrote: >>> If you follow the convention that each way should be drawn along the >>> center of the real-world feature, then the width of e.g. a sidewalk can >>> still be determined at any point along the road from just the single >>> outline area and the way position. >> >> no, if this would be possible there would be no sense at all to map >> areas. You can't see sidewalks as "just another lane", because they >> tend to be quite irregular in certain settings (unlike lanes which >> usually keep their width and have no corners and other weird points). > > I don't think this contradicts my argument. Look at the cross-section of > the road at any point: > > | * . . . .* | > > The vertical lines are road area outlines, the stars are sidewalk ways > and the dots are other "lanes". > > If we make the assumption that each way marks the center of that "lane", > we can easily calculate the width of the two sidewalks at this > particular cut through the road: It's 2 times the width between the > sidewalk and the area outline. The last time I checked, we're mapping in two dimensions, not one :-) I'm not sure that mapping the actual physical extent of the various parts of roads is feasible in terms of number of mappers and their motivation, but if anybody is serious about mapping crossings and physical properties of these areas, I think mapping them as areas is the obvious and logical way forward. We already map waterways with both a way and an area. I'd map the road, the sidewalks, connecting areas, crosswalks, parking spots, what have you, all as areas (if I felt I had exhaused housenumbers on buildings etc.) I'd probably add curbs as ways, not areas, unless they have multiple steps in them and approach a meter or so in width. Of course, that doesn't answer how anybody would be able to tell that all these features together form "the road", except for their proximity. I'd like to learn about where that information would actually be required. Stefan -- Stefan BethkeFon +49 151 14070811 ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - voting - childcare
2011/5/11 Flaimo : > http://wiki.openstreetmap.org/wiki/Proposed_features/childcare#Voting I don't see why there should be "service_hours:childcare". Can't we reuse service_times? http://wiki.openstreetmap.org/wiki/Key:service_times cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tags for neighborhoods / subdivisions
2011/5/11 : > Part of the problem is that neighborhoods, unlike official administrative > units, or even Home Owner Associations, don't necessarily have agreed-upon > boundaries. Different people may consider the same location to be in > different neighborhoods. then it's a node ;-) seriously, maybe OSM can be a system to find / establish the exact boundaries of a neighbourhood - iteratively. (or maybe they are really nodes) cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tags for neighborhoods / subdivisions
2011/5/11 Josh Doe : > Can we begin discussion of this? A "place_level" that allows for > unincorporated areas, neighborhoods, and the like. I am not sure that we need a place_level. Such a key would only make sense if there was a clear hierarchy. Place structures can be different overlapping systems without clear hierarchy. Which would get a higher place_level, unincorporated areas or neighbourhoods? A place might even really be part of 2 neighbourhoods at the same time? An unincorporated area could still get a place value like hamlet, village or town, couldn't it? cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tags for neighborhoods / subdivisions
On 5/11/2011 2:28 PM, Josh Doe wrote: On Wed, May 11, 2011 at 2:14 PM, Nathan Edgars II wrote: I agree that they're important to map. But they're not administrative units, and shouldn't be mapped as such. How do you suggest doing this without breaking the way people expect a service like Nominatim to operate? If Nominatim expects admin_level, it should be fixed. > You're proposing that I remove admin_level=* from Burke, but that is the "city" that everyone in Burke uses for their mailing address, and is indeed what the USPS uses. Are you sure the boundaries are the same? USPS city is based on zip codes. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging] Feature Proposal - Voting - childcare
I personally like when OSM definitions are linked to other references,
especially a well-known source like wikipedia.
From http://www.thefreedictionary.com/social+service:
social service
n.
1. Organized efforts to advance human welfare; social work.
2. Services, such as free school lunches, provided by a government for
its disadvantaged citizens. Often used in the plural.
or Merriam Webster, http://www.merriam-webster.com/dictionary/social%20service
: an activity designed to promote social well-being; specifically :
organized philanthropic assistance (as of the disabled or
disadvantaged)
I can add these references to the tag page if people consider them better form.
As for removing the daycare reference in social_facility, I agree that
replacing it with a link to an approved childcare feature makes sense.
There are service organizations that focus on children and I wouldn't
be surprised if some provided daycare, but this is such a specific
service that I think a node is better described by combining tags. So
a social facility that provided childcare service could use:
amenity=childcare
social_facility:for=child
age=2-17
operator=ABC Kids
--
Sean
On Tue, May 10, 2011 at 04:59, M∡rtin Koppenhoefer
wrote:
>
> Actually I perceive as well some reference to class struggle,
> especially in the introduction of the linked wikipedia article:
> "pursuit of social welfare, social change and social justice". I
> suggest to remove this reference, as it is not even helpful in its
> generic definition, and "social change", "social justice" and to some
> point also welfare are not about what it is, but why it is (so it
> belongs to philosophy / politics / economy and not to OSM). It is also
> not helpful to have the basic definition ("A social facility is any
> place where social services, as defined here, are conducted:") linked
> to a dynamic page ;-), and I think in OSM we could well live without
> the "as defined here" part.
>
> Given all this I agree that there is not yet a suggested value, but
> there is daycare as an example: "social_facility:for=child e.g.
> daycare center for children", i.e. following the logics of the cited
> page there would be social_facility=daycare, social_facility:for=child
> to be amended.
>
> Following the logics of your proposal instead, there could be an
> amendment to your proposal saying that daycare should be removed from
> the example section of social_facility:for (or a link to your tag
> added. Removing "daycare" from social_facility would not be a problem
> because there is not yet a single object with this tag in the database
> (according to taginfo),
>
> cheers,
> Martin
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
