Re: [Talk-us] Why?
On 3/4/2015 3:38 PM, stevea wrote: landuse in OSM should be the actual landuse, not the legally permitted / designed landuse (zoning). I do not disagree (meaning I agree), however: if my quarter-hectare property of low density residential zoning has a house, fences, a garage, lawns, a creek running along the backside of it and so is largely a riparian corridor, a garden and so on, are you saying that it is incorrect for me to have included my parcel in a larger neighborhood of landuse=residential (along with my neighbors), even though I don't include all of these specific micro-mapping elements? Where do you draw the lines of where appropriate landuse=residential tagging begin and end? And again, as large areas (called neighborhoods or quarters or districts in any given local parlance) truly are exclusively residential, I still maintain that drawing an appropriate polygon around them and tagging landuse=residential is correct. This (again) is NOT the same as saying that they cannot be made MORE correct, rather that such tagging is a good first step and not entirely incorrect. This is describing the actual landuse, not the legally permitted landuse. An example of describing the zoning instead of the actual landuse is marking areas of the desert with no development as landuse=residential because the government has at some point in the past zoned them as residential. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Why?
Paul Norman quotes my previous post in this thread and writes: This is describing the actual landuse, not the legally permitted landuse. An example of describing the zoning instead of the actual landuse is marking areas of the desert with no development as landuse=residential because the government has at some point in the past zoned them as residential. Paul, I agree; I understand this distinction. For example, there was a tiff in Scotts Valley, California (not far from me) circa 2009 where one OSM user entered landuse polygons directly from the published zoning map from the Scotts Valley City Council. I began to correct these where actual on-the-ground data disagreed with the zoning map. For example, many areas listed as zoned commercial are more like intended to become commercial someday but are truly residential in real life/on-the-ground, so I corrected them to be landuse=residential. I take it as widely accepted that on-the-ground landuse is much preferred to be entered into OSM than is zoned by the government landuse. The former is correct, the latter is not and should be removed or corrected. Especially when the zoning represents an intention rather than reality. What I understand Martin Koppenhoefer to say are essentially the same things, but I'm not sure if he understands (or agrees) with Escondido having large areas marked as landuse=residential. These are not simply zoned residential (they are), they ARE (on-the-ground verifiable) residential. So it is OK for them to be tagged as they are. They might also receive more detailed tagging in addition to this simple landuse polygon, a highway=residential street running through them, and not much else. These skeletal data are largely what are in OSM now across much of the USA, yes, I and many others know. However, buildings, address data, and other micro-mapping detail are being added. BOTH flavors of data are correct. While skeletal data aren't exactly preferred to largely complete data, they are not incorrect, they are just not as complete as they might be. Landuse data should show what actually IS, not simply what is zoned and especially not what is intended. Yes, zoning data are a bit raw, and may be considered early or a first step for OSM. They need updating, they change over time. They may be too broad as where 40 acres are tagged as landuse=farmland where only 39 of them actually are landuse=farmland, but one acre is a house (landuse=residential) and perhaps landuse=farmyard where the barn and tractor and irrigation supplies are. Would I rather see this perfectly mapped in OSM, exactly as I describe such micro-mapped details? Yes, absolutely. Will I say that tagging all 40 acres as landuse=farmland is totally incorrect? No, though if I or somebody else has the time to tag with those better details, OSM sure will appreciate it. Should OSM show landuse=commercial because the County Supervisors just approved a shopping center be built on this farmland in the future? Absolutely not, especially if it is still a working farm and no construction has yet started. Are we all agreed? Thanks for good, productive discussion. SteveA California ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Why?
Martin Koppenhoefer writes: landuse in OSM should be the actual landuse, not the legally permitted / designed landuse (zoning). I do not disagree (meaning I agree), however: if my quarter-hectare property of low density residential zoning has a house, fences, a garage, lawns, a creek running along the backside of it and so is largely a riparian corridor, a garden and so on, are you saying that it is incorrect for me to have included my parcel in a larger neighborhood of landuse=residential (along with my neighbors), even though I don't include all of these specific micro-mapping elements? Where do you draw the lines of where appropriate landuse=residential tagging begin and end? And again, as large areas (called neighborhoods or quarters or districts in any given local parlance) truly are exclusively residential, I still maintain that drawing an appropriate polygon around them and tagging landuse=residential is correct. This (again) is NOT the same as saying that they cannot be made MORE correct, rather that such tagging is a good first step and not entirely incorrect. Perhaps a superior/outstanding example of what you consider to be GOOD landuse tagging is now in order. Thank you in advance for a link to such data. It is easy to point someplace and say it is wrong, or bad, or needs further explanation (OSM has plenty of those). It is a bit more difficult (though possible) to point to areas (such as Escondido) and say they are on the right path to completion, but are not yet done. It is yet more difficult to point to excellent examples of landuse= tagging, so I now politely ask you to do so. Let's not let perfection be the enemy of the good. If everything entered into OSM had to be perfect upon its initial upload, we'd still be back in the Stone Age of data entry. OSM is a work in progress, and likely always will be. We can strive for excellence without demanding perfection. SteveA California ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Whole-US Garmin Map update - 2015-03-02
These are based off of Lambertus's work here: http://garmin.openstreetmap.nl If you have questions or comments about these maps, please feel free to ask. However, please do not send me private mail. The odds are, someone else will have the same questions, and by asking on the talk-us@ list, others can benefit. Downloads: http://daveh.dev.openstreetmap.org/garmin/Lambertus/2015-03-02 Map to visualize what each file contains: http://daveh.dev.openstreetmap.org/garmin/Lambertus/2015-03-02/kml/kml.html FAQ Why did you do this? I wrote scripts to joined them myself to lessen the impact of doing a large join on Lambertus's server. I've also cut them in large longitude swaths that should fit conveniently on removable media. http://daveh.dev.openstreetmap.org/garmin/Lambertus/2015-03-02 Can or should I seed the torrents? Yes!! If you use the .torrent files, please seed. That web server is in the UK, and it helps to have some peers on this side of the Atlantic. Why is my map missing small rectangular areas? There have been some missing tiles from Lambertus's map (the red rectangles), I don't see any at the moment, so you may want to update if you had issues with the last set. Why can I not copy the large files to my new SD card? If you buy a new card (especially SDHC), some are FAT16 from the factory. I had to reformat it to let me create a 2GB file. Does your map cover Mexico/Canada? Yes!! I have, for the purposes of this map, annexed Ontario in to the USA. Some areas of North America that are close to the US also just happen to get pulled in to these maps. This might not happen forever, and if you would like your non-US area to get included, let me know. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] For comment: import of amenity=bicycle_repair_stations
On Wed, Mar 4, 2015 at 9:34 PM, an UK mapper wrote wrote: Way back when, Bryce wrote: The locations need local mapping to get the location perfect. Are you intending to feed these local changes back to the data source? Will the import involve deleting any repair stations in OSM not in the data source - this doesn't seem like a good idea. A qualified yes to that. This import uses a script meant for synchronizing a commercial data set (like a list of ATM's, radar stations, or chain stores) to OSM. It prepares a changelist file describing any differences for human review. If an item drops out of the company's dataset, the OSM mapper sees that closure. Here if Dero racks removes a location it's because the property owner, their client, told them the site was removed on the ground. The human running the script can decide how to react (e.g. mirror the deletion in OSM, take no action, move the item to Open Historical Map, or tag disused:, or fly to the location and check). In the ATM or radar station case: it's the same thing. For well run corporate data sets the list of open stores, ATMs, or whatever is quite good. If an item drops out of that data it's because the location has closed. But, the human can review it, checking yelp or seeking other secondary sources or local sources for information. For this bike tool data set, OSM changes in the USA have already been sent back to the corporate source: mostly duplicate data points and more precise positioning. In general at the next sync this causes no trouble, the fuzzy match is simply less fuzzy, and no action is taken. Similarly if an item is deleted from the OSM set, a flag will be raised. Here the Dero company would be notified. This has not happened yet. The script was built for a one way synchronization, but seems to work reasonably well for this two way sync. --- The main challenge is that detecting duplicates is hard, because some proper stations are literally 60 or so meters apart, and some positioning errors are of the same magnitude. Thus the local mapper who can visit the site and work it all out. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
