@MappingMore The revert was not complete, the traffic lights that were modified were replaced by new nodes unlinked from their previous edit histories, and have not been restored. Do you recognize this pattern, or do you know this mapper?

Obrigado por remover as calçadas duplicadas. Me avise se você pretende restaurar os 43 semáforos removidos, senão eu restauro. 36 deles identificavam onde havia também travessia de pedestre controlada por semáforo.

Mapear da forma mais simples (etiquetas na via principal) minimiza o esforço de manutenção e acelera o mapeamento inicial, o que permite informar as ferramentas sobre quais vias têm infraestrutura de pedestre e quais não têm, que é a informação mais importante. Temos uma falta crônica de mapeadores nessa região e no país como um todo; optar pela forma mais complexa tende a deixar o mapa mais difícil de manter, e com isso, desatualizado. O próprio wiki relata que o estilo com calçadas separadas é um fenômeno mais da América do Norte, em boa parte porque lá a maioria das calçadas fica a uma certa distância da pista, separada dela por uma faixa de grama. Então, eu acho que seria melhor remover as calçadas separadas que você mapeou. Note que já existem algumas calçadas separadas em alguns lugares específicos da cidade - eu mapeio separado quando a situação é complexa o bastante pra exigir esse nível de detalhamento. Há ferramentas pra visualizar as duas formas juntas para entender quando é melhor uma ou outra e como conectar as duas.

Para o seu mapeamento fazer uma transição completa de modelo de mapeamento, seria necessário fazer uma série de coisas que você não fez: adicionar footway=sidewalk às vias de calçada, adicionar street:name à calçada com o nome da rua, transferir sidewalk:surface=* das calçadas que já foram mapeadas para surface=* nas novas vias de calçada, remover sidewalk:surface=* das vias principais depois de transferir, definir sidewalk=separate e adicionar foot=use_sidepath nas vias principais. Compare tudo isso com o método atual - a diferença de esforço é considerável

Nesta visualização (https://osm-tiles.james-ross.co.uk/?map=18/-30.0315/-51.2288&layer=standard&layer=overlay&layer=roads) você pode notar que várias vias do centro têm uma borda cinza, que é a calçada já mapeada como etiquetas. É um pouco mais evidente pela cor rosa aqui (https://openstreetbrowser.org/#map=18/-30.03158/-51.22999&basemap=osm-mapnik&categories=footways), mas esta visualização é mais lenta e tem uns bugs de vez em quando. A melhor forma de visualizar as calçadas mesmo é no JOSM com o estilo "Sidewalks" (que mostra calçadas mapeadas dos dois jeitos), mas para isso precisa aprender a editar o mapa com o JOSM, que exige um pouco de dedicação.

Olá! Sou o principal mantenedor dos dados de pedestres em Porto Alegre. Notei que você está adicionando calçadas separadas em vias onde elas já estavam mapeadas como etiquetas (osm.wiki/Sidewalks#How_to_map), que é o estilo predominante aqui, e também alterando o padrão de mapeamento dos semáforos (highway=traffic_signals#How_to_map). Você está fazendo isso como parte de algum projeto ou organização?

Concordo que a Westphalen como primária faz sentido. E também concordo que a Floriano Peixoto deve ser menos que primária, similar a outros sistemas triplos (República Argentina, Padre Anchieta e Paraná). As últimas duas são marcadas como secundárias em mais de um mapa comercial, bem como a Floriano Peixoto, então acho que secundária seria o ideal para elas, não terciária, mesmo com a velocidade reduzida. Contanto que as paralelas tenham uma classe superior, elas vão atrair tráfego pra si e para longe da via cental desses sistemas triplos, e a classificação como secundária serviria como indicativa da importância da via central.

Pensar que a Westphalen forma um binário com a Floriano Peixoto faz sentido apenas se entendemos que a função principal desse trecho é ligar a periferia com o centro. Ao norte da Arthur Hauer, as placas de indicação de destino nas transversais tentam jogar o tráfego indo pro centro para a Floriano Peixoto. Mas em situações como essa, onde não está bem claro o que é melhor, eu tento pensar num contexto mais amplo. O DNIT diz que a principal diferença entre as arteriais primárias (primary no OSM) e as arteriais secundárias (secondary no OSM) é a distância que elas cobrem. Então, uma ideia é pensar sobre as rotas entre regiões mais distantes ao redor do centro.

Fazendo isso (e demorei um tanto porque é muita informação a considerar; principalmente as placas de indicação de destino e os testes com sistemas de roteamento que têm padrões de tráfego reais), eu fiquei com a impressão de que a Westphalen serve como rota de passagem ao redor do centro (vindo de Santa Felicidade e do shopping Barigüi para Boqueirão), e na direção oposta, a rota Aluízio Finzetto - Francisco Nunes - Engenheiros Rebouças - Conselheiro Laurindo (vindo de Boqueirão até São Lourenço) faz o mesmo. As duas rotas então formariam uma espécie de "binário aberto" onde um lado vai pelo leste e outro pelo oeste do centro. Analisando isso, também fiquei com a impressão de que estão faltando algumas primárias. Fiz um esboço incluindo elas (em vermelho forte nesta imagem: https://imgur.com/a/hCKsM9y), mas a princípio o foco principal é fechar a malha primária na área dentro do pontilhado amarelo.

O que você acha? Isso está de acordo com a sua experiência ao se locomover por Curitiba?

Esse link está desatualizado. Esse mapa da LUOS foi atualizado pela lei 16054 em 2022 (https://ippuc.org.br/storage/uploads/5b7b74a5-e8ad-452b-8b8e-5b4d2e1864db/Lei-16.054_2022.pdf). Na versão atualizada, o eixo central segue sendo via estruturante (a princípio, primária no OSM) e as paralelas seguem sendo vias setoriais (a princípio, secundárias no OSM). Mas as LUOS geralmente fazem uma classificação por perfil físico, e no OSM buscamos uma classificação funcional em área urbana (osm.wiki/Brazil/Classifica%C3%A7%C3%A3o_das_rodovias_do_Brasil). O PlanMob estabelece que a classificação oficial é a do plano diretor (de 2015), que é funcional. Em vários casos, a LUOS e o plano diretor concordam sobre a classificação viária. O plano diretor também marca o eixo central como via estruturante (primária) e as paralelas como vias principais (secundárias). Então eu acho que faz sentido repensar essa alteração, já que ela deixou a malha primária aberta (desconectada) bem no meio da cidade. Não precisa seguir os planos exatametne, mas é arriscado divergir muito, especialmente quando não há outros mapas divergindo junto. No caso, Google e Waze não propõem um sistema primário em Curitiba, mas o Here.com sim, e ali ele considera as paralelas como primárias ao sul da BR-476 e o eixo central como primário ao norte da BR-476. As duas partes se conectam em torno da estação Tubo Ferrovila. E considera o eixo central uma via secundária. Pode ser que isso faça mais sentido. Se você realmente acha que a Westphalen é primária, daí a Rockefeller provavelmente deveria ser também (e estar conectada por vias primárias até rotatória da Francisco Nunes com a João Parolin), formando um binário que cobre toda essa extensão até se encontrar o com o binário transversal formado pela Guarapuava e a Silva Jardim no centro. O único problema é que a conexão com a malha primária na Silva Jardim ficaria incompleta, o esperado seria poder seguir até a Guarapuava para poder converter à esquerda sem sair do sistema primário.

Ao apagar as ciclovias separadas nas avenida Paraná e Santos Dumont, substituindo elas pela etiqueta cycleway;right=track nas linhas principais dessas vias, faltou remover bicycle=use_sidepath das vias principais. Sem isso, OSRM e Valhalla acabam evitando essa via mesmo quando ela é o melhor caminho para os ciclistas. Mas essas ciclovias têm separador físico com o espaço dos carros, então geralmente faria mais sentido como estava antes, como linhas separadas.

No, it's the criterion 2.3 indeed. It should apply in situations like these:

1. Northbound: osm.org/directions?engine=graphhopper_car&route=-29.84182%2C-51.17399%3B-29.9535%2C-50.99442#map=14/-29.85025/-51.14802

2. Southbound: osm.org/directions?engine=graphhopper_car&route=-29.95313%2C-50.99442%3B-29.84338%2C-51.1803#map=12/-29.8662/-51.0894

These short sections need to be trunk to maintain classification continuity along these routes as one is moving between the two roads (one motorway, the other trunk), there is no other route connecting them on these movements. If these sections are classified as secondary, these movements would follow an unexpected gradient:

1. motorway > motorway_link > secondary > trunk_link > trunk

2. trunk > motorway_link > secondary > motorway_link > motorway

"Trunk" is a functional way type and "motorway" is a physical design type. All motorways are also "trunk" from a functional standpoint. So, even functionally, the sequence is still unexpected:

1 and 2. trunk > trunk_link > secondary > trunk_link > trunk

The way to solve this is to raise the classification of the connecting stretch. But of course, this should only be done where intentional.

Taking inspiration from the section "The concept of topological continuity of highways", when one tries to select all roads that are either trunk or motorway (+ trunk_link or motorway_link), if these middle sections are classified as anything lower than trunk, there is no way to perform some turns on that interchange, so it would be impossible to travel continuously on them.

This would still be problematic if this stretch was classified as primary, as it was earlier in 2025 (my fault). The frontage roads along this specific road are functionally all second-level urban arterials (city plans do not assign them any class but they are useful for medium distance routes within the city, so we're filling in the gap in official sources here). For longer distances, one would prefer to simply take the central track than to navigate along the much slower parallel side ways.

These frontage roads were primary before because they are connected to the city's primary ways in a few places, thus a primary classification would reduce changes of classification along them. That is the main justification for classifying the frontage roads on the southern part of the city, despite them functioning more like secondary. In the northern part of this highway, this isn't needed. In Brazil, there isn't much of a practical difference between secondary and primary (typically similar design types, similar speeds, difference is mainly importance), so this slight upgrade made the map more readable and led to fewer edit reversals in that specific case.

Unfortunately, these situations in this particular road all due to poor design. This is the most lethal highway in the state of Rio Grande do Sul precisely because there is a lot of weaving between all those access ramps and often (as in this case) not enough distance between one ramp and the next.

It seems that this highway is being gradually redesigned, apparently by completely removing physical separation with what today are the frontage roads. If this becomes the final design, then we don't even need to argue about this anymore as the frontage road will cease to exist in OSM and the main highway will have an increased lane count and no change to its classification.

Thank you. One more thing I forgot to mention: I have also undone the highway classification change because it does not follow Brazil's Highway Classification (osm.wiki/Brazil/Highway_Classification_in_Brazil) rule 2.3.

I have undone this edit as it does not follow Brazil's Highway Classification (osm.wiki/Brazil/Highway_Classification_in_Brazil) rule 2.3.

Please do not remove mapped elements that still exist or are still visible in satellite imagery. These elements should be retained in the data, possibly with lifecycle prefixes (osm.wiki/Lifecycle_prefix). In this case, both links still exist. The one that had a block barrier no longer has that barrier, so it was effectively reactivated. You should have removed only the barrier.

Please do not remove mapped elements with lifecycle prefixes that still exist or are still visible in satellite imagery. These elements should be retained in the data (osm.wiki/Lifecycle_prefix). In this case, this link can be reactivated at any time simply by removing the guardrails, the pavement is practically intact.

Passo todos os dias por esse trecho da Praia de Belas e nunca vi uma placa dizendo que o limite de altura é 5,5 metros. Por favor, não insira limites fictícios no OSM, apenas os sinalizados. Se quiser indicar que deve haver um limite mas não está indicado qual, use maxheight=below_default .

E também 2020-04-19

Datas das imagens: 2025-01-01, 2025-02-10, 2025-02-25, 2025-03-14, 2025-04-28, 2025-05-13, 2025-06-10, 2025-06-25, 2025-07-10, 2025-08-21, 2025-09-23, 2025-10-08, 2025-10-23, 2025-11-19.

Datas das imagens: 2025-01-01, 2025-02-10, 2025-02-25, 2025-03-14, 2025-04-28, 2025-05-13, 2025-06-10, 2025-06-25, 2025-07-10, 2025-08-21, 2025-09-23, 2025-10-08, 2025-10-23, 2025-11-19. Desta vez a segmentação foi manual, produzindo um contorno ligeiramente mais amplo que o obtido pelo método anterior semi-automatizado.

Datas das imagens: 2025-01-01, 2025-02-10, 2025-02-25, 2025-03-14, 2025-04-28, 2025-05-13, 2025-06-10, 2025-06-25, 2025-07-10, 2025-08-21, 2025-09-23, 2025-10-08, 2025-10-23, 2025-11-19. Método: filtro threshold no GIMP ajustado manualmente para cada imagem (porque estão em condições de iluminação diferentes), média das imagens resultantes, threshold no nível 127 (50%), e por fim vetorização e ajuste das relações.

I've reverted these changes. Being drivable does not mean it is legally allowed. Those ways had a source:motor_vehicle tag referencing a local law that establishes their correct value. This law is still in effect, so, driving on them is still forbidden, except for emergency vehicles.

No OSM, nós sempre mapeamos as restrições legais, mesmo quando os moradores locais desrespeitam a lei. Em fevereiro, o HappyMapper2020 mudou motor_vehicle=no para motor_vehicle=yes sem mudar source:motor_vehicle, gerando confusão. A lei estadual 9204 não foi revogada, e ela proíbe "veículos" em geral, ou seja, o que eu mapeei em 2019 continua valendo. Por isso, já reverti essas alterações.

Os changesets desfeitos são os seguintes: 171052036, 171052013, 171051990, 171051954, 171051856, 171051842, 171051821, 171051810, 171051796, 171051786, 171051772, 171051734, 171051715, 171051698, 171051678, 171051665, 171051654, 171051642, 170174566, 170174543, 170174521, 170174493, 168811672, 168811628, 168811599, 168811590, 168811451, 168811441, 168700576