then officially would have to be tagged as : name=Double - Double when they are the same and name:fr=Double and name:nl=Double.

But I don't think this is a big problem with just using a single double. This data is often used for apps that offer multiple language support and they would fallback to the name tag when the other lack. I kinda follow you there on the translation thing.... Been looking around I also kinda doubt that 'Double' is the official name of the right building. I have a hard time finding this reference back on the website of http://www.brigittines.be/

But I would agree that the general public would refer to this building as the Double and non-official names are often valid for OSM. I'll add the website on the other building as well.

The article sure uses Double as a name even though the Brigitinnes website doesn't really refer to it like that (but the website is annoying to navigate when hoovering over the bottom menu/ mirroring title - thingy)

Woah, that's wicked. I think it's probably best when you name something to follow the community consensus for BXL to add name:fr=Double name:nl=Dubbelganger and name=Double - Dubbelganger tags (fr<space>-<space>nl) , that would probably help. But in any case, the delete of the left part is a mistake, the special tool (only runs locally, not public) that matches it does not have 'delete' logic on board, just a flag that is visualized later in JOSM using validator code / custom stylesheet to draw attention for manual review. I think I just hit the delete on the selected geometry instead of my intented (wrong) move to just supress the name tag assuming it was a mistake. Concerning the result: basically 2 buildings, surrounded by amenity. I checked the Urbis database and it also shows 2 buildings, so there's not reason why it wouldn't have matched properly when the geometries are equal within the thresholds of the hausdorf algo. I also see an issue with the source:geometry:ref and source:geometry:version tag allocated on the amenity. Those only go on buildings, but when a building also has the amenity key and later on the building is removed and it is split (which I would recommend in many cases when the building is only a part of an amenity), then those tags and also ref:UrbiS should be removed from the amenity-only way, but kept/moved to the building=* way. Verifying the source data on Urbis shows me zero reasons to legit remove the left building, so that is definitely a manual action that went haywire at the time. Thanks for pointing it out though , it was kinda confusing when you mentioned a merge that I couldn't place.

Ok, dove a bit deeper into this.

When I delete something , except the occasional mistake not intentional, I always have a pretty good reason to do so.

So here, why are you giving buildings the name = "Double" anyway ? That is probably the reason why this way got removed. If any deletes are done in a changeset it's a manual one and not an automated and most probably because there is .... erm crap data. And a name=Double kinda hits that. But I think the reason why the 'building' disapeared on the map is because you remove the building=* tag at one point. note that there is an amenity encompassing both buildings

So I think you're talking about this way: way/260918023/history

See also:
https://osmhv.openstreetmap.de/changeset.jsp?id=116516724

https://osmlab.github.io/osm-deep-history/#/way/260918023

Diving deeper here I think in essence you are mixing the amenity around both buildings with the idea that I've merged 2 buildings which isn't what happened as far as I can see in the historical viewers. I do see I deleted the left building, which seems indeed wrong, and I bet I made the mistake of tapping delete on the geometry instead of on the wrong name=Double tag, that was most probably my intention back then. But I don't see a merge. However, it would be kinda cool to restore the source:tags. I'm a bit on a hiatus on OSM after developing the building merge tool so took me longer than usual to visualize the historical action done in all the changeset.

If you care to help the building completion effort on OS, check the comments on https://osmcha.org/changesets/116516724/ on the who, why and how those tags are used in contrast to the initial ref:Urbis one
The chat channel is like the place to be .

I see you're using ID editor a lot, not sure if you know JOSM but in that one it would probably be a lot easier to see that it wasn't a merge but it was 2 buildings + 1 amenity around it.

I guess the name=Double was a mistake on your part, probably meant to end up in a comment on the changeset or a note on the building.

Glenn

Hi,
Please check https://overpass-api.de/achavi/?changeset=116516724

Atleast In this changeset the osm ID's you mention wasn't removed. I just added the correct backreferences to the source Urbis data.

When I check your mods in this changeset https://overpass-api.de/achavi/?changeset=123537940 it's in fact you that removed the building=* tag from the left part and also removed the source tags that were added by this algorithm. This process doesn't delete buildings, it just does a matching with current Urbis database. so I am not sure why you think I deleted it. Please check the changesets with Achavi and try not to delete / try to keep the source:* tags . Also see the comment changesets if you want to help with buildings, it's probably better to not use the ID editor for this work.

Hallo Jozin,
I see you're an ID user, it must be a lot of work doing this in ID. And we have a tool that can help you to merge/create houses easily but it uses JOSM as a way to import buildings. The empty area's you did here can be done in 5 minutes with it. In cases you're interested, we hang out at https://app.element.io/?#/room/#osmbe-grb:matrix.org

Als, check out https://buildings.osm.be for the tool, before using it, drop by in our channel so we can assist.

Thanks for contributing!

No we're not importing those again. There are many problems with that dataset, Streetnames issues, the 3D set isn't all that great as far as I can see, the initial import of Urbis also gave a problem since the unique reference was imported but there is no version control, unline GRB and Picc who have a date of the modification of a feature which we can use to see if a feature is more recent than OSM or not, urbis just has a version number and it wasn't included in the initial import years ago, the map was also pretty empty so back then it was ok, but now it's not that easy to import, especially not automated. The tool I wrote is semi-automated (https://grbosm.site) and combines Picc, GRB and Urbis data, they also sometimes overlap and weed in the other ones garden. Next to those problems, the import is not really the biggest challenge, it's updating it afterwards that is an issue. So for Brussels I wrote a program that matches on geometries withing a margin, quite small and add "source:geometry:*" tags on it (ref and version). That way we can diff visually between source data and OSM. In that process the addresses are also completed and corrected where it's needed. The 3D dataset is also not like GRB , we actually use the 3D dataset in the tool to create auto_building tags were we can (just hover in flanders over a building or 2)

There just tons of problems with these, a lot technical, the 3D set of Urbis is very much in many parts, which do not quite map well on the OSM datamodel (let alone on the 3D OSM model(s)). Too many elements to transmigrate to OSM. And a lot of the 2D buildings are already badly addressed or mapped. Also many of the old ref:UrbIS are wrong now, not in the Urbis data anymore. Urbis is a meltpot of diffent sources , autoimport/conversion that are not coheren, I could go on about everything I found in there that is really not ok.
At this point, the goal is to get the referfences to match and the addressing to be more complete, next step is plug the holes and make it future-ready for updates.

This is the url you want btw: https://datastore.brussels/web/

ps disclaimer: I actually work at CIRB/CIBG (bric) who maintains/hosts and controls the URBIS dataset (but I'm on database side, not gis) . But it's way too political

Hi,
Yea, no worries, I understand. Urbis is hell, I'm geomatching old imports of buildings to the new Urbis database using matching and addressing from Urbis, we're now discussing those problems in the chat, because even though I fix a lot, it seems by trusting Urbis in the wrong places I introduce new errors, I wasn't thinking of you doing an edit war, but I'm thinking of the next guy, not knowledgeable enough to realize Urbis has errors in it. We're going to build a proper database with the correct names , the tool I wrote to import URbis/Grb/Picc buildings from all communes depends on it being correct, even though we do fix obvious mistakes. The fix you did was indeed the correct one, I skipped checking the street signs because I was probably tired. I wrote different programs to match geometries , add missing addresses and validate existing ones but also to flag errors which I manually verify before upload, I don't even know anymore why I decided the bad one was the good one, but the next mapper is just going to 'corrrect' again and our goals are to get this sorted out and get a spell-corrected list of street names out there that no-one can deliver. I also wrote a algorithm to build a list of problematic street names in brussels that don't match up with Urbis. We'll get it done, but thanks for correcting this. I'm talking to my peers in the chat channel to get this sorted out correctly. tx for the link on nominatim, didn't know that QA one. will use it as well.

Hi JuanjoMC,

Would it interest you in joining our chat channel, the streetnames are food for many discussions, thanks for restoring the work I did on getting it corrected. But still we have a long way to go, since Urbis is not without errors. We have a continuous effort going on there to distill the best out of urbis and osm, so I never just change this lightly without serious research. It would be cool to have you join us. We're trying to prevent edit wars. Thanks for the help in completing and improving Brussels.

Ok, thanks . I know it detects it, but I'm talking about a program I wrote that detects it and fixes it automatically in an JOSM xml osm file automatically, it actually works already, just not made for embassies. But don't worry, it's besides the scope of the topic. The detection is easy.