@Fizzie41, I am not leaving OSM. I will continue to assist in my local OSMP community and maintain all projects, as they remain valuable to many people. My decision is to discontinue involvement in global OSM issues, as I intend to shift my focus towards other matters.

I appreciate both Simon and spatialia taking the time to respond and share their thoughts.

1) I’m well aware of the entirety of the conversations that took place, which is why I would urge anyone commenting here to carefully reread the diary, as it already addresses many of your concerns.

2) While I acknowledge that the thread was locked to ‘cool things down’, it’s worth noting that this occurred at a time when activity had already subsided. It seemed a tad selective in allowing only one side to continue sharing their thoughts, which felt inconsistent and censorship-like.

3) Conversations become truly productive when both sides provide justified reasoning for their positions. I’ve been earnestly looking for such constructive exchanges.

Great work, Dónal! Always inspiring to see such dedication to OpenStreetMap. 👍

@SimonPoole What was the point? I did not get it, sorry.

@SimonPoole This is indeed quite a similar project. Thank you for sharing it with me; I was not aware of it. However, I still believe there are some key differences that differentiate my project. YOLO Crossings is open source, allowing anyone to build on top of it and use it. On the other hand, I could not find the source code for the Zebra Safari project, but this could be due to a language barrier.

Secondly, YOLO Crossings is optimized for fully autonomous mapping, with a very high precision threshold set to avoid adding false positive crossings. While it may not map all crossings, it significantly reduces the amount of work required by mappers by automatically marking easy and medium difficulty crossings.

^ Sorry for poor formatting, something has gone wrong.

What do you even mean by accuracy? I primarily mean the precision metric, but I use simpler terminology better understood by everyday people. Scoring code starts here https://github.com/Zaczero/osm-budynki-orto-import/blob/e899e4c2e14bced34fde4be02c4bb9b674381b25/model.py#L143

What is your IoU threshold? None, the dataset is labeled in a way that answers the question: “is this building acceptable for an import as-is?”. The idea is to automatically import buildings, which from a human perspective, don’t require much modification.

With this approach, the model is able to import about 70% of valid buildings as-is. The remaining 30% requires some modification from the model’s perspective and are not imported automatically. For clarity, 100% would be all buildings which are visible at an orthophoto imagery.

@simonschaufi Yes, I am :-) But the primary goal here is slightly different. I want to create solutions that require little to no human intervention, this way mappers can be significantly more productive, instead of doing the same repetitive tasks over and over again. RapiD still requires complete human attention to make any changes, which is a more universal solution and is very low risk.

@iWowik I think you meant to ask for a confidence interval (based on the +-30% number you added). Percentage is unit-less and accuracy in this case is irrelevant as precision is more informative about the false positive error rate.

This number is a precision achieved on the holdout dataset: containing 600 entries: 500 buildings (True) and 100 non-buildings (False). Using https://en.wikipedia.org/wiki/Binomial_proportion_confidence_interval method, the 90% confidence interval is 99.3%-100%. But it’s been some time since I last did it so excuse me any mistakes. This is really not my field of expertise atm. I might be talking completely out of the blue here.

The holdout validation code starts from here: https://github.com/Zaczero/osm-budynki-orto-import/blob/43cce7c88c898939fafb8f24087882ee4f88c0e9/model.py#L115.

@giggie, I’ve just added support for that :-)

@giggie, I am already aware of this issue, and I have plans to address it in the future. Thank you for feedback :-) !

@ToniE, simply pass a “relation” query parameter: https://relatify.monicz.dev/?relation=123. In the future I may also add a &load=1 support (to automatically load the given relation), so if you want to stay future-proof you may also consider adding this parameter: https://relatify.monicz.dev/?relation=123&load=1.

@MatthiasMatthias - Yup! I definitely want to add this.

Hey everyone! The gateway issue should be fixed now. There is a bug within the HTTP library I use (https://github.com/encode/httpcore/issues/642) that causes a connection pool leakage. After some time, it prevents new connections from being made, resulting in a 504 timeout. I have disabled the connection pool functionality, which will most likely resolve this issue.

Hey! Right now you can only edit existing relations, meaning that if you want to add a new route, you will first need to create it in another editor (doesn’t need to be complete). Then you can simply fix it in Relatify. New relation creation is on the roadmap.

@Woazboat, I run my own Overpass instance that updates every 30 seconds from the minute replication server (https://planet.openstreetmap.org/replication/minute/). There should not be more than a one-minute delay on my end. Additionally, there is a fallback to the official Overpass instance (overpass-api.de) in case the returned data is not complete or if my server fails to respond. Related code at https://github.com/Zaczero/osm-revert/blob/72f9c659d1d16591ec5566daa90c08d4d96c6340/app/overpass.py#L93-L96

@Cristoffs Sama aplikacja nie posiada ograniczeń co do ilości zestawów do wycofania. Jednakże na stronie jest ustawiony sztuczny limit 10 zestawów. Zrobiłem to w celu zabezpieczenia przed masowo skalowanym wandalizmem i aby uniknąć wysokiego zużycia zasobów serwera. Od kilku lat istniała już inna aplikacja bez tego typu ograniczeń, i o ile mi wiadomo to nic poważnego się nie wydarzyło - https://github.com/Zverik/simple-revert.

However, I have implemented…*

@Fizzie41 There is none in the application itself which is Open Source on GitHub. I have implemented a hard limit of 10 changesets on the website to prevent potential large-scale vandalism and to conserve resources. I don’t believe that in a reasonable scenario, you would want to revert more than 10 changesets at a time.

@TomH I believe that even with or without this tool, edit wars would still continue to occur (as they currently do). Therefore, I do not see this as a barrier to improving our current revert tools. However, after reading your comment, I think adding a simple requirement of having at least 10 edits could be a good idea. I will implement this change shortly.