search

praszuk / josm-plbuildings-plugin

PlBuildings plugin for JOSM editor.
GNU General Public License v3.0
8 stars 0 forks source link

uncommon tags check #3

Open flohoff opened 1 year ago

flohoff commented 1 year ago

Hi, is there a way either to disable that check, or to add more tags?

I wrote an exporter/API for German ALKIS Datasets and those contain a lot more information on the building type e.g. carport, garage, roof, power substation, barn, stable, farm_auxilary and i return those tags which produce popups.

So it would be great to have a config option to disable that check.

Flo

flohoff commented 1 year ago

This is the preliminary perl module mapping "Gebaeudefunkion" from the German ALKIS to OSM Tags:

https://github.com/flohoff/plbuildingsnrw/blob/master/ALKISGFK2OSMTags.pm

praszuk commented 1 year ago

Hi, I'm glad to hear that my plugin can be used in other countries too :smiley:.

is there a way either to disable that check, or to add more tags?

At this moment, there is no possibility of doing this, but of course I can look into it. Excluding new values for building tag should be pretty easy, but combined tags like this would be problematic. Actually for me it is an uncommon tag, don't you think that? Adding option to completely disable this check is the easiest way to solve your problem, but I don't want to take that feature away from you, because it is being helpful if someone edits a lot.

Other "meta" question: How much it is bothering you? I mean, do you need it to be resolved for now, or it can wait until next major release?

And about major release. From version 2.0.0 (which probably will be the next) I'm going to change the payload format in the client-server communication which will be incompatible with 1.x versions anymore. At this moment I don't have final schema yet, but I can create issue or send pm via OpenStreetMap when it will be ready, to adjust it on your side.

flohoff commented 1 year ago

Complete disable would be okay for me. I built the plugin disabling it in the code for now.

So dont bother with it until next major release. It just a "minor annoyance".

In the end the German Cadastre (depends on the open data export) has a lot of information i am translating into osm tags. Other versions i am right now have in the makings also contains building:levels, start_date etc.

No worries - new format would be fine with me.

Whats the reasoning for changing the format?

Flo

praszuk commented 1 year ago

So dont bother with it until next major release. It just a "minor annoyance".

Ok.

Whats the reasoning for changing the format?

I want to implement the possibility of using multiple data sources (in simple and advanced meaning), so probably one additional request will be required (to get available data sources):

  1. By simple I mean just switching between data sources.
  2. By advanced I mean possibility of using two ds at the same time and combining them (e.g. ds1 geometry, ds2 tags) – but this one will be more complicated to properly handle, so I'm not sure it yet and don't know if it will be good enough for mappers.

I'm not sure about data format too, for now it uses "OSM JSON", but I don't know if it will be directly GeoJSON instead, but if it will be possible I would handle both.

Currently in Poland we have WMS of EGiB ("Ewidencja Gruntów i Budynków") which provides good edges of buildings and people use it to (re)draw buildings. My plugin for this moment uses second data source BDOT ("Baza danych obiektów topograficznych") which also contains buildings, but unfortunately shape is not always great (but has better tags). Local municipal offices with general country-level ministry currently working on vectorizing EGiB and sharing as WFS, so it could be used in future to e.g. importing data to OSM.

flohoff commented 1 year ago

I thought about the same, e.g. for Northrhine-Westfalia we also have addresses. These are IIRC nodes within the outline of the building.

But i would implement that server-side. E.g. after fetching the outlines i would enrich it with tags by doing an ST_Within in the postgis for finding possible addresses.

But i could not see a solution for a single outline containing multiple addresses, which we have. I'd need to either ignore them, or add 2 nodes to the result - No clue what would happen. (I also did not implement converting WKT Multipolygons to correct result with Multipolygon Relation.)

Switching datasources would be great though. But implementing it by fetching a List of Datasource would also require to change the URI manually if you would use a different server. So i'd rather go for something like the Imagery setup. Add an editable list of datasources, select active ones from them. The polish ones could be a predefined list compiled into the plugin.

Flo