Talk:Layer (Disambiguation)/Archive

Convenience Layers

Note: I suggest to move the following entirely to the discussion section because it is rather a discussion than a fixed concept.

Why have layers

Altogether: Are you aware that you can easily, with a large number of tools, filter for one or several tags? Most can be today already achieved with this.

• Reduces accidental edits/deletions/conflicts

Actually, this makes accidental editing worse. Take for example streets and landuse. Whenever a street gets refined, the landuse should be aligned again to the street. Or more generally: If the data is in the same database, users expect that the database as a whole is consistent.

• Reduces data download volume during editing making it faster for areas with high data density. Simplifies editing by selectively hiding layers.

You can have both already if you download only filtered data.

• Simplifies data distribution and transformation

Could you explain this please? In general, data distribution is not a problem at all.

• Simplifies change monitoring

Why should this help? All the software to track changes would need to get more complex.

• Simplifies layer configuration for map rendering

Once again: How could layers help? The rendering styles will be with or without configured by tags.

• Allows overlapping datasets in the database by supporting layer branches

• Allows data imports to be staged and handled/merged without destroying existing data

Jochen has already explained that it makes more sense to have it in a separate database. The most compelling reason is the license.

• In line with GIS practices

Please note that we aim for simple editing. Traditional GIS systems are geared towards mixing data from different sources. So it may or may not help.

Why not to have layers

• API changes
• Added software complexity
• Added data processing overhead

Proposed OSM layers

Any class of geographic objects that have minimal nodes/ways in common with another class can be a layer. Data is automatically distributed into these layers based on the tags they have. If the tags do not match any layer rule, it sits in the default streetmap layer.

Some obvious layers are:

• @Coastline: Low tide line
• @Natural : Natural features
• @Landuse : Landuse classification polygons
• @Building: Building footprints
• @Streetmap : All surface features and infrastructure, the default layer
• @Manmade: Power line, water and gas pipelines
• @Admin: Administrative borders
• @Navigation: Air or water routes and navigation infrastructure

Layers can also have branches like @Admin/UN-2005, @Admin/CIA which can allow a user to switch the particular layer to an older dataset, import or source. This allows normally overlapping data to be preserved without discarding it.

There can also be special types of meta branches that allow access to historical or deleted layer states like @Admin[24-12-2004] or @Admin[deleted]

API changes required

• A new property for nodes that indicate if it is referenced by more than one object. Can also be used to reduce conflicts by downloading other referencing objects before being modified/deleted.
• Api calls to fetch data only from certain layers

Scenarios using OSM layers

• OSM editors can choose which layers to ignore while editing so that download size/time is lower and map clutter is less.
• Software does not allow a shared node in different layers to be moved/deleted till all the referencing objects are downloaded ensuring data integrity
• Based on the visible layers, the tools or presets can automatically adapt to be more focused to work on certain types of features
• An unlimited number of overlapping data imports are now possible without destroying the existing dataset
• Data imports into a branch layer allows easy merging of objects into the master branch