On Tue, Jun 7, 2011 at 9:41 AM, Frederik Ramm <frede...@remote.org> wrote: > we have this recurring topic in various parts of OSM - airspace mapping. > > I'm strictly against it.
I'm not 100% for it, and my feeling when reading this mail was that you are too categorically against this type of mapping. I will first comment on you action plan that you hid on the bottom: > I would like to end this discussion once and for all, or at least for the > near future, and create a wiki page named "Aviation", to which I would link > from the "Aeroways" page and from "Airspace", and I would also close the > "Proposed Feature" with a link to that page. Yes, but can I add docs about it on Key:airpace=* > On the "Aviation" page, I would write up the reasons against airspace > mapping, basically as given above and on the "mapping-for-aviation" help > page, concluding that mapping for aviation is discouraged Yes, but I think the most important question is about the copyright and the discouragement of too large and unhandleable imports. (neither which seems to be a problem atm.) > On that page I would also suggest that someone who is reasonably interested > should set up a rails port instance of their own, complete with a rendering > chain to generate half-transparent tiles that can be overlaid over a > standard map. And I would even offer them my help in doing that. Considering how vital the OSM sysadmin team is I'm sure that is going to be a bit of a problem.. ;-) If it is a standard procedure that the OSM-F will host other free geographic data on their servers then sure this is a good idea. Here is what I think: First of all, years ago I was dead set against cluttering OSM data[1], but things change. Are you sure you guys are argumenting for OSM instead of just wanting to keep your data unecessarily clean, considering that Openstreetmap strives to provide free geographic data. The only valid arguments against would be as someone said, I think it ws JRA, the *import* of Corine Landcoverage and other huge "easily" accesible datasets into Openstreetmap database is troublesome. > 1. Imports of un-observable things that are defined by other people should > be kept to an absolute minimum in OSM. [paraphrase] But let say 0.1% of them are observable can I map that? Adding flight paths for my local airport most certainly would be a usefull thing to have, since it really is very noticeable that planes fly by every ~15min every morning and evening. That seems to be a very valid type of "free geographic data". And I thought the idea about crowdsourcing was "good enough". > 2. Airspace data should be in a parallel system maintained by a flying > enthusiast.[paraphrase] To me that just seems like a very subtle way to blow people off, > 3. Airspace boundaries cut right across the country, and clutters [paraphrase] Clutter in the database is also very subjective, there are several things that clutter the DB.. e.g. * 3dShapes * bus routes * turn restriction * landuse * buildings * abutters=residential * boundaries But since Openstreetmap strives to provide free geographic data, not specifically a map, they are included. Hence it is already a storehouse for stuff with coordinated that change a lot by external parties.. It really is a pain to edit OSM when all these cluttering features are there on the map. I don't see a problem with adding another layer of clutter just because you guys are used to it doesn't mean it's easy. > 4. 99% of Airspace is of almost no significance to non-pilots. [paraphrase] But then that 1% (or 0.1%)is what is causing the concern, it's that 0.1% that actually is mappable. > 5. Pilots would not use a crowdsourced airspace map;[paraphrase] Bad argument, same goes for many things in OSM. > 6. airspace is published is on printed, copyrighted maps [paraphrase] Big problem. [1] I thought adding abutters=residential was cluttering the data _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
