Tere! Leian, et OSMi aadressiandmed võiksid olla ajakohased. Arvestades nende mahtu, siis nende käsitsi haldamine ja uuendamine pole realistlik. Pakun välja, et hoonete puhul võiks neid uuendada automaatselt ja regulaarselt. Tegin skripti, millega saab ADSi andmeid hoonete geomeetria järgi OSMi importida. Siin on muudatuste eelvaade: https://ads-osm-preview.web.app/
I think it’s important to keep address data in OSM up to date. Doing it manually is not practical. My proposal is to have regular imports from ADS. I wrote a script that does this and here is the preview of the changes: https://ads-osm-preview.web.app/
This is great and I’ve felt a strong lack of something like this, amazing work.
As far as I know previously addresses were imported by @SviMik and then @fghj753
Is there a plan to do batch imports or create an interface to merge tags case-by-case?
Is there a plan to also import new building geometry?
Another thing I think we lack is automatic destroyed building detection. Previous imports only added buildings, but as I’m mapping I often see outdated buildings.
It would be cool if there was a different outline colour for buildings which have differences in street/housenumber/housename/county, that way we could see how bad the situation is for the most important tags.
How do you handle multiple addresses? Previous imports put them into addr2:, while I prefer to have a separate address node with normal addr: tags.
This building is not outlined, is only one match done for Maa-amet’s address?
https://xgis.maaamet.ee/adsavalik/EE01926735
I’ve been mapping old town lately and building geometry there often differs from Maa-amet, sometimes it’s correct as you’d see two distinct buildings from the street, while Maa-amet has merged them.
Maa-amet provides monthly ADS extracts. After initial import, which updates over 12% of EE buildings, the plan is to set the script up as a bot, that runs every month.
Importing new buildings is fairly simple, but updating and maintaining them is completely different topic. Currently I’d rather focus on maintaining existing data.
Since I’m already comparing OSM vs ETAK building geometry, I can set up some kind of page in the future, where mismatched data is shown.
Currently the preview page is slightly modified version of achavi. I’ll need to check, maybe I can also change the colors.
Buildings with multiple addresses are skipped. There are only 855 of such buildings and the trend is clearly declining. The reason is that I want to avoid such edge cases like this: way/745837030
But addr2/3/4 tags are removed if there is only single address in ADS.
I want to keep building geometry comparison as simple as possible and currently each OSM building needs to have 1:1 relationship with Maa-amet building. There are valid cases to have OSM building geometry different from Maa-amet, but such buildings are skipped at the moment.
Blue - When only postcode or ETAK ref is added. This clearly shows why most of buildings in Tallinn and other cities are updated.
Red - at least one address component tags is removed. Typically happens when housenames address are replaced by street and housenumber.
Yellow - at least one address component tag is updated.
Green - New address tags are added / with some other minor cases as well
The biggest issue I’ve noticed is how addr:housename is used. In many cases it contains useful information about the building but it doesn’t align with ADS. Here are few examples: Ragnar Nurkse kolmiktorn, Metro Plaza
I think those are building names, but we probably can’t assume that invalid housenames can always be moved to name tag. And moving them to old_addr:housename isn’t always right too, since they never were a part of the address.
Maybe add “fixme=housename is missing in Maa-amet, review if should be moved to name or deleted”?
Though if housenames were removed in rural places, it’s a high chance that the removal was correct.
Just to be sure, are buildings with multiple addresses ignored completely? https://xgis.maaamet.ee/adsavalik/ads?ads_oid=CU02103528
Here one address is mapped in OSM as a node, and the other one on the building. The import is suggesting to change the building address to be the same as the node reducing data quality. But I think this is due to anomaly in Maa-amet that the cadastral unit has 2 addresses, while the building currently has only one. I haven’t found any changes to other buildings with multiple addresses.
While the trend for multiple addresses per building may decline in Maa-amet, OSM has some buildings which are not split and this import would change one correct address to another.
Multiple addresses for buildings are skipped, address data for cadastral units is not used.
These two examples where OSM and Maa-amet building have different geometry - I need to tweak how geometry is matched. These buildings should be skipped.
Fixme is a good idea. For Tallinn/Tartu I could easily add fixme=old_addr:housename to the tags. Since I’m hoping to run this script automatically in future I don’t want to just blindly overwrite tags.
Here is another strange behavior I noticed - Karljohan changed street names of imported buildings from Johann Voldemar Jannseni → J. V. Jannseni. While wiki suggest to use long version of street name in addresses, this is ok by my script since it aligns with ADS.
Here is the same thing with Tammsaare pst, but since there is no space between “A.H.” this doesn’t align with ADS, and my script will overwrite it to long variant
Maybe not now, but I do think that in future something has to be done about all of the buildings. There are many private houses which have additional buildings and those buildings had an address assigned. It would be confusing to have different addresses on a land plot. It could be solved either by assigning address for everything on a cadastral unit, or by using non-main address objects from Maa-amet.
And here I even see that a non-main address object was selected for update
And maybe not only buildings. There are mappers who love adding addresses to everything they see (Hi, @Zverik!), I’m not sure how good this practice is, but the reality is that they will get outdated.
Adjusted the geometry match for buildings. It may still need to be fine-tuned but currently it is a bit stricter. Previous update size was 110k buildings, now its down to 90k buildings. Also added Maa-ameti basemap to preview site.
I also checked cadastral units, it’s quite messy. Not only can cadastral unit have buildings with different addresses, but a single building (1) can overlap with multiple (1, 2) cadastral units.
Any other feedback on geometry matching or on ADS tag alignment? Personally I’m happy with current results and see no reason to why to delay with this import. There are couple of formal steps needed, but I can already start with these.
After improving geometry matching I relaxed this constraint. If existing OSM building has maaamet:ETAK that aligns with ADS, then there can also be n:1 relation. Example: Lasnamäe 4b overlaps with way/551322371 and way/551322370, but is only matched with the first one, since it has ETAK code. Second part can’t be matched since it overlaps with multiple Maa-amet buildings. Neighboring 4c isn’t matched since it doesn’t have the ETAK code.
@qqqqqqqqqqqqqqqqqqqq, sure, the scope of what could be imported from different Maa-amet datasets is much greater, but as starting point I rather limit scope and don’t try to fix every invalid or incomplete address.
Address data import from ADS is an import from ADS (Address Data System), maintained by Maa-amet, covering Estonia. The import is currently at the planning stage.
to
Address data import from ADS is an import from ADS (Address Data System, maintained by Maa-amet), covering Estonia. The import is currently at the planning stage.
To avoid misunderstanding that Maa-amet maintains this import.
Some stats, based on test run from couple of days ago:
Number of buildings¹ in OSM: 852 858
Geometry is matched with Maa-amet ETAK: 86%
Addr tags updated: 12%
[¹] - this is without relations/multipolygon buildings. These are skipped for now. I plan to include them on the next import.
I’ve also identified two additional post import tasks:
Reviewing and cleaning up newly generated old_addr:housename tags. I will add fixme notes as needed.
Removing some of the addr nodes. These must be inside building with correct address and provide no additional value (not have additional tags like name / addr:flats / addr:unit etc)
These will be partly manual, partly mechanical edits, but not scripted.
First I would like to thank @dgmapping for the work on this useful importing solution.
I’ve had a look at the changesets at different locations and everything seems to be fine. The only thing I noticed, that with current setup we will overwrite
When it comes to source:addr:2023, I believe it would only create confusion, if the outdated source:addr tag is retained alongside updated address. OSM keeps history and with tools like Deep History it is very easy to see who and when made the changes. In this example you can also see that SviMik replaced 2012 source:addr value with 2019 during the import. Based on taginfo and overpass data, this source:addr:2023 tag hasn’t gained any adoption at all.
@SherbetS, sure, I will include all these changeset tags. Some of them are a little redundant, but in this case it doesn’t really matter.
