Re: [Talk-us] Admin borders in the US
i originally brought this up here because i am dealing with border issues in the US. however, this would need to be implemented world wide, i think, so i'll broach the subject on talk for a more general discussion. On 11/4/13 3:03 AM, Simon Poole wrote: IMHO we shouldn't and I don't believe it is necessary to, give up the principle of everybody can edit anything, even in the case of admin borders. On the one hand we have cases where the borders are estimates generated by mappers because there are no available and free sources, on the other hand we can react faster to changes than your typical government GIS agency (example: we have a largish number of municipality mergers each year here, 2012 around 40, we had merged boarder polygons available months before the official ones were available). As a consequence I think it would be best to have borders (and other similar objects) in a separate DB/layer/whatever (makes live simpler for nearly everybody and stops the typical accident from happening), but the data should still be edited by our standard tools (in other words the API should stay the same) and by anybody with a OSM account. Simon ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us signature.asc Description: OpenPGP digital signature ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Admin borders proposal
this is a copy of what i sent to talk@osm i'd prefer it if further discussion went forward over there. i brought up the subject of admin borders in the US over on talk-us and there was a lot of useful discussion. i think folks are mostly clear on the issues and tradeoffs, so i'd like to float a proposal for an evolved approach. i'm moving the discussion here because it's not just a US thing. basically, having admin borders mixed into the core OSM map is problematic for various reasons. in the US, we have a bunch of uncoordinated imports from different, inconsistent sources, and a bunch of hand editing that is sometimes well intentioned, and sometimes accidental, and not always correct. the resulting map can be quite ugly at times. there is an argument that some make that because borders are usually not easily verifiable on the ground, they don't belong in OSM at all. i'm somewhat sympathetic with the argument, but i also think that we have a bunch of data consumers that need/want borders. many map users, not so concerned with philosophical purity, expect to see at least some of these borders in a map. so the rough outlines of the proposal (feel free to kick this around) are as follows: a new database is created under the framework of OSM. the purpose of this DB is to contain borders. after it is reasonably complete and data consumers have been adapted to use it for their admin border needs, the old admin borders can be removed from OSM core. it uses the same schema and API so existing tools all work for editing. it has the same access restrictions as the current core OSM database; the only barrier to entry is that you have to learn enough about your editor to repoint it at this new DB. every member of the OSM community would retain the same access rights they have now. the minor barrier to entry, combined with the fact that it will be impossible to glue border nodes to other features, will probably address 98 or 99% of the issues we see today. for the US, we'd probably want to do a fresh build of borders, mostly from current TIGER although in some areas other sources might be more appropriate (for example, in Massachusetts MassGIS is available and probably a better choice.) one open question is do we move other borders into this map? there are lots of things like the New York State DEC borders for various bits of conserved land, National Park National Forest borders, and so forth that maybe out to move with admin borders. but perhaps we should start with admin borders only for proof of concept and to control the amount of work that needs to be done. richard signature.asc Description: OpenPGP digital signature ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Call for Locations: 2014 Winter #Editathon!
http://openstreetmap.us/2013/11/january-winter-editathon/ Our next #Editathon will be held the weekend of January 18-19, 2014. We've opened up a call for locations [1]-- so add your city to the list! During our most recent editathon we had 12 cities participating, and the event has been growing steadily over the last year. If you've considered hosting a local mapping party in the past, this is a great opportunity to get your feet wet. Hosting an editathon is easier than you think. See some helpful suggestions here [2]. Editathons are great opportunities to focus on what your local community wants and needs. Is there a local contingent with a strong interest in improving city parks on OSM? Maybe you have a lot of folks who are interested in OSM, but have never actually contributed before and just need someone to show them the ropes? Maybe it's a combination of many things. Whatever your local community is looking for is the right thing to focus on, and the #editathon is a great time to do just that. Please feel free to reach out if you have any questions, but otherwise, I'm looking forward to seeing what cities will be participating in the first #editathon of 2014! Mappily Yours, Kathleen [1] http://openstreetmap.us/2013/11/january-winter-editathon/ [2] http://openstreetmap.us/2013/07/why-editathons/ ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin borders in the US
I don't mean to pour water on what is a sizzling and robust conversation -- quite the opposite. But as a computer scientist, I don't see how putting (moving, creating anew...) borders (and WHAT other objects -- we likely need to be careful in our design of what we mean by these objects and similar objects) into a separate DB/layer/whatever can be achieved by the API staying the same, and continuing to be edited by our standard tools. I'm not saying this cannot be done, or should not be done, I'm just asking for a sharper focus on HOW it could be done. Because leaving alone the API and tools effectively perplexes me. Maybe that's just me, but can we think our way out of this? With good design, civil discussion and the technical prowess required to do so? It seems we have arrived at a bit of consensus, which is a nice starting place: early agreement that a separate DB/layer/whatever might be editable by our standard tools, and the API should stay the same. We might need to be a bit more flexible on that last point, I'm not sure. But is that a good goal to continue to discuss as what we (roughly) want to address this issue? Thank you, SteveA California On 11/4/13 3:03 AM, Simon Poole wrote: As a consequence I think it would be best to have borders (and other similar objects) in a separate DB/layer/whatever (makes live simpler for nearly everybody and stops the typical accident from happening), but the data should still be edited by our standard tools (in other words the API should stay the same) and by anybody with a OSM account. this is approximately what i had in mind. richard ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin borders in the US
On 11/5/13 6:59 PM, stevea wrote: I don't mean to pour water on what is a sizzling and robust conversation -- quite the opposite. But as a computer scientist, I don't see how putting (moving, creating anew...) borders (and WHAT other objects -- we likely need to be careful in our design of what we mean by these objects and similar objects) into a separate DB/layer/whatever can be achieved by the API staying the same, and continuing to be edited by our standard tools. umm, use a different port with the same xml api pointed at a different DB? this is hardly rocket science - this is speaking as a computer scientist and a network engineer in two of my previous careers. richard signature.asc Description: OpenPGP digital signature ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
