[Talk-us] The best import
One OSM commenter suggested that the best thing for the map was an import, Import some German mappers they suggested. That isn't wrong, but in some places it might be historically provocative. :-) About 18 months ago I posted this Mappy Hour HOWTO. http://lists.openstreetmap.org/pipermail/talk-us/2011-June/006023.html I don't think anyone has bothered to try it. I'm not aware of a single city in the US with current monthly local meetings for mappers. Try it. They're a lot of fun and help grow the local mapping (and map using) community. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] parcel data in OSM
I am generally opposed to importation of parcel data at the individual parcel level. This goes _directly_ to the design of OSM with a non-layered data model and the resultant massive increase in rendered data density.However, there is much information in local GIS datastores about subdivision and town boundaries which did not come in with the 2005 TiGER import. Given the large number of populated place nodes added from the USGS GNIS, addition of these administrative boundaries directly complements the GNIS node imports, with the resultant enhancement of the relationship between Wikipedia and OSM via the WIWOSM functionality.There is also information from town charter documents which is not necessarily represented in other GIS resources; such town charter documents refer in places to actual ground artifacts visible during town boundary surveying (such as "...three following described courses and distances: (1) South 63°-05'-40" West, and passing through a 48 inch tulip poplar tree" fromhttp://charters.delaware.gov/arden.shtml). If I had the wherewithal, it would be really interesting to following on the ground the boundary details and document them in OSM; this would be an absolutely unique set of data which links written survey descriptions with ground truth, thereby making OSM more physically verifiable than the GIS datasets themselves (in this small data area).--OSM contributor ceyockey ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] An admin_level for CDPs?
On 12/31/12 5:12 PM, Minh Nguyen wrote: I'd argue that not all governmental boundaries need to be tagged as boundary=administrative. In Ohio, we've started to retag CDP boundaries with boundary=census and place=locality but without admin_level. [1][2] They still show up in Nominatim as localities. this is approximately what i was thinking should be done with CDPs. This sounds workable to me, as well. It is agreeable that CDPs not have an assigned admin_level, I was opening this for discussion to see if there might be wider consensus. CDPs *are* created by the Bureau of the Census, but the *SAs are not, they are created by the Office of Management and Budget (OMB). It *does* beg the question of what *should* be tagged as boundary=administrative *and* have an admin_level tag. For example, my local University of California campus has a polygon tagged boundary=administrative, border_type=university (and amenity=university + name=*). Might/should it also be tagged admin_level=4? Even though it partially overlaps (and largely is in) City Limits, it *is* an administrative unit of state government (neither city/local nor county) with its own police, fire and health-care infrastructure, its own planning and development functions and a recent lawsuit (since dismissed) between it and its host city, proving it and the city are different entities. The same question (admin_level=4) might also be asked about California State Park boundaries...but they are *already* tagged with admin_level=4, so at least there is precedent (thanks, Apo42) for state-level units with specific administrative boundaries to be tagged with admin_level. I'd like that to become widespread among all 50 states, which also implies national parks get tagged with admin_level=2. State/national parks and state universities really do have their own administrations, and this implies an admin_level tag. In states that give civil townships some authority, they are much more important to the identity of an unincorporated area than CDPs. The TIGER boundary import excluded Ohio townships, so Vid the Kid and I have been painstakinglly filling them in. i have started filling in Towns in upstate NY as well. i don't mind identifying the Hamlets in some manner, but all they consist of typically is a boundary drawn by the Census, and some green-and-white signs posted by the NYS DOT in traditional locations by the road side. there's no government there, whereas the towns maintain roads, provide the framework for the volunteer fire districts, have a zoning master plan functions, inspect buildings construction, and so forth. richard What I found useful to do around here (where there are CDP polygons entered from TIGER, but they have no admin_level tag) is to add a point tagged hamlet=* or village=* or town=* (but not necessarily suburb=* as that implies city subordination, nor city=* as that implies incorporation) to the approximate center point of the CDP polygon, along with a name=* tag that matches the name of the CDP. This point might logically be a mathematical centroid, but I have found it more useful to place this point at a more culturally significant point in the human center of the community designated by the CDP. Usually this is at or near a significant crossroads, where there might be a market, a church, a school, a small commercial district, or the like. What I am hearing: there are many polygons in OSM with the tag boundary=administrative, but it makes sense for only some of them to have an admin_level tag. (This seems odd, but gets solved in the case of CDPs having their boundary=administrative tag changed to boundary=census). We agree on nation, state, county and city (2, 4, 6, 8), but there really are other polygons upon which we might appropriately add an admin_level tag, state parks being one of them. CDPs, no, but changing their tag from boundary=administrative to boundary=census seems a good idea. And for other *SAs designated by the OMB (not the Bureau of the Census)? What about those? Finally, while there seems to be no argument that New York City is 5, and LAFCos in California are 7, what about MPOs? These are a odd blend of where a locality's transportation planning agency wants to qualify for federal money, so they create an MPO per federal Code which qualifies them for it. This MPO becomes a de facto and de jure administrative boundary, for both local and federal reasons, effectively bypassing state-level government. Do we want to assign MPOs an admin_level tag in OSM? (I'm guessing no, but I feel the need to offer due diligence that at least this question was asked). SteveA California ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] NC Mappers near Charlotte, please contact me off list
i have observed some things along I 85 north of Charlotte that could use some attention from a local mapper. please contact me off list if you are in a position to go look at some stuff and i'll give you all the details. thanks, richard ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] An admin_level for CDPs?
Zip code areas and voting districts seem to me to be be functionally equivalent to CPDs in that they are arbitrary geographic distinctions determined by agencies outside of local governments or administrations. Are they given a boundary=administrative? For most administrative boundaries, one side of the boundary (the interior) is actually administrated. (Administered?) The other side (the exterior) is not. That doesn't seem to be the case with CPDs, zips, or voting districts. That said, that rule doesn't really help with college campuses, school districts, school attendance areas, transit authority zones, UASI areas, fire districts, post office delivery areas, etc. Does administrative really mean governmental? Unfortunately, it's not clear that that helps, either, as school districts can be municipalities. Is there a master list / Rosetta Stone somewhere of these various entities recommended tagging? On Tue, Jan 1, 2013 at 2:18 PM, stevea stevea...@softworkers.com wrote: On 12/31/12 5:12 PM, Minh Nguyen wrote: I'd argue that not all governmental boundaries need to be tagged as boundary=administrative. In Ohio, we've started to retag CDP boundaries with boundary=census and place=locality but without admin_level. [1][2] They still show up in Nominatim as localities. this is approximately what i was thinking should be done with CDPs. This sounds workable to me, as well. It is agreeable that CDPs not have an assigned admin_level, I was opening this for discussion to see if there might be wider consensus. CDPs *are* created by the Bureau of the Census, but the *SAs are not, they are created by the Office of Management and Budget (OMB). It *does* beg the question of what *should* be tagged as boundary=administrative *and* have an admin_level tag. For example, my local University of California campus has a polygon tagged boundary=administrative, border_type=university (and amenity=university + name=*). Might/should it also be tagged admin_level=4? Even though it partially overlaps (and largely is in) City Limits, it *is* an administrative unit of state government (neither city/local nor county) with its own police, fire and health-care infrastructure, its own planning and development functions and a recent lawsuit (since dismissed) between it and its host city, proving it and the city are different entities. The same question (admin_level=4) might also be asked about California State Park boundaries...but they are *already* tagged with admin_level=4, so at least there is precedent (thanks, Apo42) for state-level units with specific administrative boundaries to be tagged with admin_level. I'd like that to become widespread among all 50 states, which also implies national parks get tagged with admin_level=2. State/national parks and state universities really do have their own administrations, and this implies an admin_level tag. In states that give civil townships some authority, they are much more important to the identity of an unincorporated area than CDPs. The TIGER boundary import excluded Ohio townships, so Vid the Kid and I have been painstakinglly filling them in. i have started filling in Towns in upstate NY as well. i don't mind identifying the Hamlets in some manner, but all they consist of typically is a boundary drawn by the Census, and some green-and-white signs posted by the NYS DOT in traditional locations by the road side. there's no government there, whereas the towns maintain roads, provide the framework for the volunteer fire districts, have a zoning master plan functions, inspect buildings construction, and so forth. richard What I found useful to do around here (where there are CDP polygons entered from TIGER, but they have no admin_level tag) is to add a point tagged hamlet=* or village=* or town=* (but not necessarily suburb=* as that implies city subordination, nor city=* as that implies incorporation) to the approximate center point of the CDP polygon, along with a name=* tag that matches the name of the CDP. This point might logically be a mathematical centroid, but I have found it more useful to place this point at a more culturally significant point in the human center of the community designated by the CDP. Usually this is at or near a significant crossroads, where there might be a market, a church, a school, a small commercial district, or the like. What I am hearing: there are many polygons in OSM with the tag boundary=administrative, but it makes sense for only some of them to have an admin_level tag. (This seems odd, but gets solved in the case of CDPs having their boundary=administrative tag changed to boundary=census). We agree on nation, state, county and city (2, 4, 6, 8), but there really are other polygons upon which we might appropriately add an admin_level tag, state parks being one of them. CDPs, no, but changing their tag from boundary=administrative to boundary=census seems
Re: [Talk-us] An admin_level for CDPs?
On 1/1/13 6:52 PM, Jeff Meyer wrote: Zip code areas and voting districts seem to me to be be functionally equivalent to CPDs in that they are arbitrary geographic distinctions determined by agencies outside of local governments or administrations. Are they given a boundary=administrative? zip codes don't even properly belong in the discussion as there is no such thing as an official zip code area. the post office sees them as routes, not areas, and the Census zip code boundaries are a synthetic approximation. richard ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] An admin_level for CDPs?
From: stevea [mailto:stevea...@softworkers.com] Sent: Monday, December 31, 2012 12:31 PM To: talk-us@openstreetmap.org Subject: [Talk-us] An admin_level for CDPs? I have been pondering the use of the admin_level key in the USA, and have come to the realization that while values 2, 4, 6 and 8 are correct for national, state, county and city boundaries (respectively), it is more complicated than that. One minor point, although I realize your message doesn't actually raise this issue directly. People often assume that because admin_level=6 is used to tag counties in most of the US an admin_level=6 area is the same as a county. Most of the states have a very similar structure for administrative divisions so most people don't encounter the other structures. In Alaska as well as other parts of the world there are no counties. Other administrative divisions are used, not because they're the equivalent of counties but because they're what admin_level=6 means locally. This is perhaps more relevant in the US to cities where there are more definitions of what they are. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] An admin_level for CDPs?
{{key|border_type}} is described as an alternative and sometimes complement to
{{key|admin_level}} . I have recently been drawing subdivision boundaries
based on County GIS data and including {{tag|border_type|subdivision}} as part
of a relation of type border; see for instance
http://www.openstreetmap.org/browse/relation/2672911 . --ceyockey
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Adopt-a-highway representation in OSM
I am interested in what tagging you would suggest to indicate that a stretch of
road has been adopted as part of an Adopt-a-Highway program.
Quoting from the Wikipedia article: The Adopt-a-Highway program, also known as
Sponsor-a-Highway (but see distinction below), is a promotional campaign
undertaken by U.S. states, Provinces and Territories of Canada, and national
governments outside North America to encourage volunteers to keep a section of
a highway free from litter. In exchange for regular litter removal, an
organization (such as Cub Scouts or Knights of Columbus) is allowed to have its
name posted on a sign in the section of the highways they maintain.
My thinking right now would be to include at the way level these additional
tags:
...amenity {Adopt-a-Highway}
...operator:amenity {Air Liquide}
...source:amenity {survey}
...source:amenity:date {2013-01-01}
...source_ref:amenity {roadside_sign}
An example changeset containing two contiguous road segments is at
http://www.openstreetmap.org/browse/changeset/14493979 .
Thanks for your input.
--ceyockey
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Adopt-a-highway representation in OSM
On Tue, Jan 1, 2013 at 7:32 PM, dies38...@mypacks.net wrote:
I am interested in what tagging you would suggest to indicate that a stretch
of road has been adopted as part of an Adopt-a-Highway program.
My thinking right now would be to include at the way level these additional
tags:
...amenity {Adopt-a-Highway}
...operator:amenity {Air Liquide}
...source:amenity {survey}
...source:amenity:date {2013-01-01}
...source_ref:amenity {roadside_sign}
The source:amenity tag should be a source tag on the changeset. The
changeset also records the time of changeset, so there's no need for
that source:amenity:date.
I don't know what this source_ref:amenity means, but from the context,
it seems part of your description of sourcing, which should be part of
the changeset, which is how we handle metadata.
As for amenity, I don't think that fits. You may want to talk to the
tagging list about tagging systems for this.
- Serge
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] An admin_level for CDPs?
On 2013-01-01 2:18 PM, stevea wrote: On 12/31/12 5:12 PM, Minh Nguyen wrote: I'd argue that not all governmental boundaries need to be tagged as boundary=administrative. In Ohio, we've started to retag CDP boundaries with boundary=census and place=locality but without admin_level. [1][2] They still show up in Nominatim as localities. this is approximately what i was thinking should be done with CDPs. This sounds workable to me, as well. It is agreeable that CDPs not have an assigned admin_level, I was opening this for discussion to see if there might be wider consensus. CDPs *are* created by the Bureau of the Census, but the *SAs are not, they are created by the Office of Management and Budget (OMB). Ah, my mistake. I'm not fundamentally opposed to putting in statistical areas; I just think it may be less confusing to use some other value of boundary=* (even with admin_level set), rather than overloading boundary=administrative for what evidently isn't a straightforward hierarchy of government entities. It's specialized information, less important than your typical city/county distinctions when completing the sentence This business is located in... It *does* beg the question of what *should* be tagged as boundary=administrative *and* have an admin_level tag. For example, my local University of California campus has a polygon tagged boundary=administrative, border_type=university (and amenity=university + name=*). Might/should it also be tagged admin_level=4? Even though it partially overlaps (and largely is in) City Limits, it *is* an administrative unit of state government (neither city/local nor county) with its own police, fire and health-care infrastructure, its own planning and development functions and a recent lawsuit (since dismissed) between it and its host city, proving it and the city are different entities. I never really saw the need to tag state college campuses as boundary=administrative, just amenity=university, but some of the UCs do operate like cities unto themselves. The UC extension in Cincinnati ;-) has a neighborhood council that almost corresponds to the campus boundaries, so I mapped the neighborhood separately with admin_level=10. However, I don't think it always makes sense to tag public property as boundary=administrative based solely on who owns the land. In Ohio [1], a city can own property outside its limits: the City of Cincinnati recently sold a general aviation airport back to the suburb it's in, but it wouldn't've made sense to tag the airport as an exclave of Cincinnati. State law prohibits municipal exclaves, and it isn't as if any Welcome to Cincinnati signs were posted there. Also, a city or village can annex public property (such as a county park or public university) without the government agency's consent. [2] People describe public lands as being inside townships or municipalities, not as enclaves of them. The same question (admin_level=4) might also be asked about California State Park boundaries...but they are *already* tagged with admin_level=4, so at least there is precedent (thanks, Apo42) for state-level units with specific administrative boundaries to be tagged with admin_level. I'd like that to become widespread among all 50 states, which also implies national parks get tagged with admin_level=2. State/national parks and state universities really do have their own administrations, and this implies an admin_level tag. I think you meant that national parks would get admin_level=4 and state parks admin_level=6. Otherwise, you'd make national parks into nations. I've only mapped a couple of state parks, but here I'm also of the opinion that parks should get something other than boundary=administrative. Following examples in California, I've been overloading admin_level to indicate the admin_level of the operator (=2 for national, =4 for state, =6 for county). But if you combine admin_level=4 with boundary=administrative for national parks and so on, then national parks would conceptually be peers with states and state parks peers with counties. They may be subordinate to the same authority, but they aren't peers. So instead I've been misusing boundary=national_park, combining it with admin_level=4 for state parks. It stinks, but boundary=protected_area looks like a good way out of this mess. [3][4] What I found useful to do around here (where there are CDP polygons entered from TIGER, but they have no admin_level tag) is to add a point tagged hamlet=* or village=* or town=* (but not necessarily suburb=* as that implies city subordination, nor city=* as that implies incorporation) to the approximate center point of the CDP polygon, along with a name=* tag that matches the name of the CDP. This point might logically be a mathematical centroid, but I have found it more useful to place this point at a more culturally significant point in the human center of the community designated by the CDP.
Re: [Talk-us] An admin_level for CDPs?
On 2013-01-01 4:29 PM, dies38...@mypacks.net
wrote:
{{key|border_type}} is described as an alternative and sometimes complement to
{{key|admin_level}} . I have recently been drawing subdivision boundaries
based on County GIS data and including {{tag|border_type|subdivision}} as part
of a relation of type border; see for instance
http://www.openstreetmap.org/browse/relation/2672911 . --ceyockey
I've also been using border_type as a way of distinguishing between
cities and villages, which have the same admin_level in my state.
However, I've been content with mapping suburban subdivisions as landuse
areas rather than boundary relations. It's a lot easier for other
mappers to work with.
The benefit of admin_level is that renderers know what to do with them
right out of the box, whereas every country has different border_type
values with different levels of significance.
--
Minh Nguyen m...@1ec5.org
Jabber: m...@1ec5.org; Blog: http://notes.1ec5.org/
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Adopt-a-highway representation in OSM
Thanks for your comments, Serge. I'm confused by your reference to changeset
metadata as that is not easily accessible to future editors of the same ways.
It would put informative content remove from the editing process.
I've made reply comments in-line below.
--ceyockey
-Original Message-
From: Serge Wroclawski emac...@gmail.com
Sent: Jan 1, 2013 7:54 PM
To: dies38...@mypacks.net
Cc: osm talk us talk-us@openstreetmap.org
Subject: Re: [Talk-us] Adopt-a-highway representation in OSM
On Tue, Jan 1, 2013 at 7:32 PM, dies38...@mypacks.net wrote:
I am interested in what tagging you would suggest to indicate that a stretch
of road has been adopted as part of an Adopt-a-Highway program.
My thinking right now would be to include at the way level these additional
tags:
...amenity {Adopt-a-Highway}
...operator:amenity {Air Liquide}
...source:amenity {survey}
...source:amenity:date {2013-01-01}
...source_ref:amenity {roadside_sign}
The source:amenity tag should be a source tag on the changeset. The
changeset also records the time of changeset, so there's no need for
that source:amenity:date.
source:amenity:date refers to the date on which the survey was done, which just
happens to coincide with the date of entering the data. The survey could just
as easily have been done 6 months ago, in which case, the source:amenity:date
might be 2012-06-01, for example.
I don't know what this source_ref:amenity means, but from the context,
it seems part of your description of sourcing, which should be part of
the changeset, which is how we handle metadata.
Without association of a description of the source with the tag, there is no
way for editors to know where the information came from. They should not have
to dig into the changeset metadata to find out that the amenity information
came from a roadside sign. For one of the ways, we're at Edit #4. Say we get
to Edit #20 and someone wants to find out where the amenity information came
from; it would be a major sifting activity through changesets to uncover that
information.
As for amenity, I don't think that fits. You may want to talk to the
tagging list about tagging systems for this.
Amenity as in the adopt-a-highway outcome is a cleaner roadway.
- Serge
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Adopt-a-highway representation in OSM
On Tue, Jan 1, 2013 at 8:33 PM, dies38...@mypacks.net wrote: Thanks for your comments, Serge. I'm confused by your reference to changeset metadata as that is not easily accessible to future editors of the same ways. Changeset tags are accessible to editors just as easily accessible as regular tags are. They're stored alongside the object, and provide more information about the changes. This issue of changeset metadata has been discussed many times, and source tags on objects (and especially metadata about source tags) are generally not used and are deprecated. Source tags on changesets make a lot of sense, on the other hand. If you want to think about it in another way, all object tags are about the object. The information about how the information about the object got into OSM is contained in the changeset, and thus the changeset tags. source:amenity:date refers to the date on which the survey was done, which just happens to coincide with the date of entering the data. The survey could just as easily have been done 6 months ago, in which case, the source:amenity:date might be 2012-06-01, for example. You can add that to the changeset tags, if you want. It's really not related to the object, but the edit (see above). I don't know what this source_ref:amenity means, but from the context, it seems part of your description of sourcing, which should be part of the changeset, which is how we handle metadata. Without association of a description of the source with the tag, there is no way for editors to know where the information came from. Hopefully your question about this has been answered now. They should not have to dig into the changeset metadata to find out that the amenity information came from a roadside sign. Knowing how data was sourced is only important for historical reasons. Users and editors don't care about source at this level, and we've depreciated source tags on objects for a reason. For one of the ways, we're at Edit #4. Say we get to Edit #20 and someone wants to find out where the amenity information came from; it would be a major sifting activity through changesets to uncover that information. It's a single call to the API, or if you're in Josm, Ctrl-H, or if you're on the web, click the history page for the object, etc. Checking editing history is something OSM editors are used to doing. But if you still have questions, please join the tagging list, since this is a tagging discussion. Amenity as in the adopt-a-highway outcome is a cleaner roadway. Please join the tagging list and discuss. - Serge ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Adopt-a-highway representation in OSM
The amenity tag is way too overloaded to the point where it is pretty
useless. It might as well be thing instead of amenity. Do not use it
for new things. Why not just make a new tag like
adopt_a_highway=name of organization - it only requires one tag to
encode to encode the information and is much more obvious.
I would agree with Serge that things like the survey date should be
put on a changeset tag. I'm not quite as sold on the source=* tag on
objects being completely deprecated though. I still use them
occasionally although I do try to avoid them.
Toby
On Tue, Jan 1, 2013 at 7:33 PM, dies38...@mypacks.net wrote:
Thanks for your comments, Serge. I'm confused by your reference to changeset
metadata as that is not easily accessible to future editors of the same ways.
It would put informative content remove from the editing process.
I've made reply comments in-line below.
--ceyockey
-Original Message-
From: Serge Wroclawski emac...@gmail.com
Sent: Jan 1, 2013 7:54 PM
To: dies38...@mypacks.net
Cc: osm talk us talk-us@openstreetmap.org
Subject: Re: [Talk-us] Adopt-a-highway representation in OSM
On Tue, Jan 1, 2013 at 7:32 PM, dies38...@mypacks.net wrote:
I am interested in what tagging you would suggest to indicate that a
stretch of road has been adopted as part of an Adopt-a-Highway program.
My thinking right now would be to include at the way level these additional
tags:
...amenity {Adopt-a-Highway}
...operator:amenity {Air Liquide}
...source:amenity {survey}
...source:amenity:date {2013-01-01}
...source_ref:amenity {roadside_sign}
The source:amenity tag should be a source tag on the changeset. The
changeset also records the time of changeset, so there's no need for
that source:amenity:date.
source:amenity:date refers to the date on which the survey was done, which
just happens to coincide with the date of entering the data. The survey
could just as easily have been done 6 months ago, in which case, the
source:amenity:date might be 2012-06-01, for example.
I don't know what this source_ref:amenity means, but from the context,
it seems part of your description of sourcing, which should be part of
the changeset, which is how we handle metadata.
Without association of a description of the source with the tag, there is no
way for editors to know where the information came from. They should not
have to dig into the changeset metadata to find out that the amenity
information came from a roadside sign. For one of the ways, we're at Edit
#4. Say we get to Edit #20 and someone wants to find out where the amenity
information came from; it would be a major sifting activity through
changesets to uncover that information.
As for amenity, I don't think that fits. You may want to talk to the
tagging list about tagging systems for this.
Amenity as in the adopt-a-highway outcome is a cleaner roadway.
- Serge
___
Talk-us mailing list
Talk-us@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-us
