[Talk-us] Imports (by nmixter in Fresno and elsewhere)
Dear Nathan, I've accidentally come across some of your imports in the Fresno area and found that they had many problems - just the usual import stuff really, over-noding, mapping individual building plots as residential areas, over-tagging, landuse areas matching neither the aerial imagery nor the existing road grid which would have been avoided by the suggested manual inspection, and so on. This is just a random example - the whole area looks like this: http://www.openstreetmap.org/#map=16/36.7379/-120.1027 I really wonder how anyone, ever, will want to make edits in places mapped like this - I think you have had similar feedback for other things you've done over the past (California FMMP residential discussion others). In an older Email you wrote of your work that California is no longer a barren wilderness but has blossomed into a flower full of color and life - frankly what jumps at me from these map pages is certainly not life! But I know that I'm probably on an extreme side of the spectrum here and there will be others who like that kind of colour map, and hence I don't want to discuss how these existing imports can be fixed or whether they should be removed altogether - that's for another time maybe. But I would like to ask you to discuss every single future import that you make *before* you make it, just like everyone else is expected to. Just because you have done many imports in the past doesn't mean that rules don't apply to you - and you don't show any signs of stopping. So please, if you must continue to import data, at least do it using the usual process. Thank you Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Denver Area Relation Assistance
I did a quick fix for the hole in the Denver, Denver County and Adams county relations. I may take another look at the area tonight. I saw a few oddities although I don't think they are related to your edit. I don't think way 321010352 should have aeroway tags on it since it is a member of a relation with those tags. There is also an odd multipolygon relation (112849) in the area that I suspect is mostly a duplicate of the Aurora boundary. Toby On Fri, Jan 9, 2015 at 10:55 AM, Jim McAndrew j...@loc8.us wrote: Kristen, If nobody else takes this on, I can look at it this weekend. -- Jim On Thu, Jan 8, 2015 at 11:21 AM, Kam, Kristen krist...@telenav.com wrote: Good Morning OSMers, A Telenav data integrity check picked up geometry issues associated with the Denver International Airport Route relation. We found that the culprit was the following changesets: * http://www.openstreetmap.org/changeset/27705328 * http://www.openstreetmap.org/changeset/27713462 I contacted the user who said essentially said the changesets were committed accidentally and didn't know how to reverse them. In any case, I reverted the deletions by creating _new_ OSM ways that are duplicates (tags geometries) of the ways that were deleted. The two ways are: *Denver International Airport (321010352, v1) *321010349, v1 These new ways (321010352, 321010349) are duplicates of ways that were part of the following relations: *Adams County (1411346) *Denver County (1411339) *Denver (253750) *Denver International Airport (112192) I went ahead and added the new ways to the Denver International Airport relation member list. However, I am not very confident on reconstructing the other boundary relations' member lists. That said, I am writing to ask if anyone can pitch in on fixing the other four relations. Thank you in advance! Best, Kristen --- Kristen Kam OSM Profile → http://www.openstreetmap.org/user/KristenK ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Place classifications
Recently I've been trying to improve the distribution of place=village versus place=town in my area. Originally municipalities were tagged based on their populations, resulting in clusters of place=cities in urban and suburban areas and a desert of place=hamlets everywhere else. And there's a lot of everywhere else in Ohio and Kentucky. Generally speaking, I've been promoting the county seat and other significant municipalities in each county from place=village to place=town. The result is 1-2 place=towns in each rural county, a bit more along Interstates. It looks nice on the standard map, but more importantly, it accurately reflects what going to town means in the surrounding area. That seems to be the idea behind the wiki's nebulous definitions. [1] Meanwhile, over in Indiana, one mapper has been turning virtually every place POI into place=town, even unincorporated places with nothing but a house or two. [2] I'm sure that's too extreme, and I just reached out to the mapper to say as much. But after browsing various parts of the U.S., I think we've all got different ideas of what a city, town, and village ought to be. Some metropolitan areas have lots of place=city POIs, while in other places 3-4 U.S. routes converge on a place=village. I think we should reserve place=city for the focal point of each metropolitan area and distribute place=town more evenly across the landscape. Just as the highway tag summarizes disparate tags like surface, maxspeed, and lanes, the place tag holistically sums up admin_level, border_type, and population (and the admin_centre role for county seats). So for example, the Walden County seat (population 900) and a Bigopolis suburb of 15,000 should both be place=town. Or has everyone settled on a different standard? Sometimes it's hard to tell whether the state of the map is due to a long-ago import to be fixed or a community consensus to be respected, and the wiki hedges too much to be helpful. [1] http://wiki.osm.org/wiki/Key:place [2] http://overpass-turbo.eu/s/6VW -- m...@nguyen.cincinnati.oh.us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] CDP tagging
On 1/9/15 2:32 AM, Minh Nguyen wrote: Taginfo currently shows over 2,000 instances of boundary=census, both for CDPs and for statistical boundaries in other countries. [1] I use boundary=census. If it weren't already in such wide use, I would've gone with the more generic-sounding boundary=statistical, but whatever. Another mapper in Ohio prefers to delete the boundary and admin_level tags but leave place=locality in place. [2] IMO the important thing is to remove the misleading administrative tags. i wonder how many actual users of boundary=census there are. if there are none, then it's a good time to consider changing it. note that the US Census Bureau itself categorizes these as statistical boundaries not census boundaries. arguably a census boundary is one that they use when doing a census, and includes both Legal boundaries and the additional statistical boundaries. The TIGERcnl import apparently only brought in CDPs, but the Census defines a whole hierarchy of areas, including metropolitan statistical areas (MSAs), census county divisions (CCDs), and census tracts. [3] If we ever attempted to map them, boundary=census and boundary=statistical would be equally ambiguous and a tag similar to admin_level would be required. However, there doesn't seem to have been much demand for including these other Census features in OSM. (For that matter, if TIGERcnl had left out CDPs, I would've preferred to seem them mapped as POIs at centroids rather than as areas. Even where the CDP name is widely used, the boundary is less clear-cut than a city limit.) there are people who use these boundaries today out there, but they are not expecting to get them from OSM and they probably shouldn't be getting them from OSM. the statistical boundaries are subject to change. there are substantial differences between the CDPs from the 2008 import and the CDPs in TIGER2014. i think CDP boundaries are very clear cut, but they morph frequently, have no legal standing, and don't necessarily correspond to what local residents think. richard -- rwe...@averillpark.net Averill Park Networking - GIS IT Consulting OpenStreetMap - PostgreSQL - Linux Java - Web Applications - Search ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
