> > Additionally, although not critical to the import, you state that this import > is for the "OpenSeaMap" database. OpenSeaMap is just one of many consumers of > the OpenStreetMap database. There is no part of the DB that "belongs" to > OpenSeaMap.
Why not? My experiences after creating a few naval chart apps with NOAA data is that many sailors want to be sure that the data is up-to-date. NOAA ENC is updated in daily basis, I really doubt if the OSM community can keep up with this pace. These naval charts in general have different data creation and update logic from OSM, so separate database could be better option. I would suggest: a) convert data to OSM format, but do not import it to OSM, create separate "OpenSeaMap database" instead, which has just NOAA data. Keep it up to date using NOAA updates. Use this database to render OpenSeaMap, in addition to OSM database. It would mean some duplicate objects, but you could tag these OpenSeaMap objects as "exists in OSM" and hide them from rendering. b) These OSM files can shared also, to be used by community to map certain local areas. Like Bay area community would update OSM in the area. But make always sure that the imported data is maintainable, as merging community-created changes and NOAA updates is huge and evergrowing manual work what you cannot avoid. Do not import anything more than the community can really update. c) If you really need to import automatically the data to OSM, then do it for one small area, and then make sure if updating by community (and your scripts perhaps) really works. This testing takes time, I would say 6 months minimum; better if a year. It is technically very easy to import all this to OSM, but really hard to maintain it later. And OSM is not about map per se, it is about live community maintained map. Jaak _______________________________________________ Imports mailing list [email protected] http://lists.openstreetmap.org/listinfo/imports
