Hey community. I was trying to fix a mapping I made using an area instead of an relation but I just can’t seem to fix it. (It’s this one, and it seems to be duplicated/repeated too as another relation but also incorrect). I tried installing JOSM but I couldn’t quite get my grip on it and ended up not being able to use it.
This is, personal consideration, an important thing for the city because recently a law (No. 29142/2026, it’s in portuguese) was passed that made neighbourhoods/suburbs (Bairros) have an official border, and they follow the new 2023 district borders, who also need to be updated.
Does anyone know how to fix this border issue? Thanks.
I took a look at the area but gave up, since it’s currently an utter mess (places modeled as areas, which are then glued to roads and administrative boundaries – see e.g. this one, particularly its nodes) and I’m not sufficiently familiar with the situation to make competent changes.
I would start with untagging the mess, and first creating a clean, non-overlapping boundary “grid” that is not glued to physical features. Here’s my work-in-progress in your area that I’m reluctant to save, but seems to show the iD setup that unclutters the display:
That means, for each place=quarter or neighbourhood in iD:
Select its area
Disconnect it from everything (you may need to zoom out in iD or even main browser control)
Add the tag boundary=administrative
Select one boundary line and its “corner” point using Shift
Split the line (X). Repeat for all its corner points.
If needed, replace type=multipolygon with type=boundary in newly created relation
Repeat for every adjacent neighborhood.
Now you have many type=boundary relations, but they have overlapping boundary lines. “Merge” them by deleting duplicates:
remove way from relation
delete the way
add the underlying way to the relation so that it’s a closed area again. Connect the corner nodes as needed.
Pay attention to keep the old administrative boundary relations intact (but you may split their outer ways as needed for your finer division).
For example, the Campeche boundary is currently modeled fine… no it’s not. This is a bloody mess - this tiny bridge is part of 19 relations, 3 of which are administrative boundaries. I don’t know what to suggest…
Thank you for helping me. I’ll try it on later today.
And I’m really sorry that I made you go through all that. I remember some people using a revert option to revert edits, do you think reverting all of my edits that caused a mess (e.g. adding districts without changing borders, adding U.E.P.s as areas, adding new regions…) would fix it?
Ah, now I realized that there currently are two Campeche relations: the new one (recently added by you) and the old one.
The old administrative boundary is, on a technical level, a mess, since it used existing instead of duplicate ways. I did not dig deep into the data, but even the version 1 of Campeche relation used major highways and waterways as boundaries, against the advice in Wiki.
However, avoid connecting boundaries to physical features like woods or rivers or reusing their ways as boundaries (one feature, one OSM element). Sooner or later these features change in reality and get updated in OSM – but usually the shape of the boundary remains. An exception may be done if the boundary is legally defined to be the physical feature.
16 versions later, after many highway splits because of maxspeed and whatnot, it has 61 boundary ways, most of them physical… that makes the map uneditable for many use cases… (for example, iD won’t let you disconnect two ways that belong to the same relation, even if you want it temporarily).
I would rather kill those old relations, since they are barely editable. Your new areas are a better start. Please read the introduction to Relation:boundary. In a nutshell:
Outer (boundary ways) should be plain, untagged ways. Remove those tags first.
Those ways should not share nodes with highways, waterways, and other physical features. Disconnect them ([D] shortcut in iD).
Those ways should be shared (not duplicated) among neighboring administrative units. For example, this section should be a single way which is outer for both Ribeirão da Ilha and Campeche (not two ways) – so, split them at the “corner” node and delete one duplicate.
This is still going to be a tedious job depending on how many relations you want to convert. There’s currently a maze of admin_level=8, 9, 10 and place=suburb, quarter, neighbourhood that I find hard to navigate as an outsider.
If you’d like me to, I can convert one pair of areas (such as Campeche & Ribeirão da Ilha) to relations in such manner, and you do the rest afterwards.
The new one is the district, the old one is the “bairro”. I tried adding the districts first but I didn’t know how to edit correctly at the time.
From what I know the person who first made Campeche as a bairro used a fake, unnoficial map. It only had official boundaries defined some days ago (apr 10). I take a guess they might’ve been a begginer and didn’t really know how to map too.
I was planning on getting rid of the failed attempts I made on the districts (Campeche, Coqueiros, Estreito, Sede/Florianópolis), update them, to map this time correctly, and than map the new bairros with official boundaries (all of those that don’t have the border marked in the map, like Costa da Lagoa or Mozambique Beach).
I’d gladly accept that, it’ll help a lot. I’m unsure if I’ll be able to edit soon cause of schoolwork and some things I have to do, but I’ll make sure I’ll also help.
I also wanted to get rid of the Spacial Planning Units being areas (Fazenda Cordeiro, Lavouras, East Campeche, South Trindade, West Jurerê, and so on…), but at this point I added around…40? Of the 133, I’m not really sure, but I know it’ll be extremely tedious to fix it…
in the meantime, I’ll currently add the official “bairros” for the following districts since they suffered no district border changes:
Rio Vermelho; Ingleses; Cachoeira do Bom Jesus; Ratones; St. Antônio, Canasvieiras and Pântano do Sul
These ones in red incase you don’t know. Green is Barra
Barra da Lagoa is debatable, as it’s made up of only 1 bairro. So would it be kind of like duplicating it? Or no?
(edit: I’ll also add regions as official bairros if they didn’t get changed by district borders.
e.g.: Costa da Lagoa, Ribeirão and Alto Ribeirão would be fine, but Carianos, Campeche, Rio Tavares and Lagoa da Conceição not.)
I tried to clean up the mess in changeset 181670757, but I ended up short. I probably introduced a few new errors – please check out “Areas” view of OSM inspector when it updates later in the day.
Boundary lines should never or share nodes with roads or streams. I duplicated several lines and moved them a tad away from the roads so that they can be selected. Now the bus routes go along roads, and administrative units meet at imaginary boundary lines.
As an exception, having boundary lines at natural=coastline is generally acceptable.
Boundary lines should not overlap each other. Instead, one boundary line should participate in multiple relations.
Those boundary=statistical, place=quarter should not be modeled as simple closed ways, and are best deleted and started anew like proper boundary relations, with shared boundary lines.
There are many such issues to fix, I did not dare dig deeper…
…oh, and I had to nuke Saco dos Limões, since it was a ~1000 node closed way which ran over the coastline, roads, and surrounding administrative boundaries.
