Incorrect dots and inaccuracies among city profiles

[tigerpranke]

Giving all entries in the profile of Aarschot coordinates is not fixing. Wrong postcodes or typos shouldn't get coordinates.

[LArdennais]

For cities, we take first the City's name, even if the postcode is wrong, and the coordinates are all fixed. An exception is to have, into the City, a hamlet : the hamlet will have its own cordinates BUT it will be included into the City for stat's.

[tigerpranke]

Giving all entries in the profile of Aarschot coordinates is not fixing. Wrong postcodes or typos shouldn't get coordinates.

This is what I ment. Do you spot the difference?

Aarschot.jpg (128.51 KiB) Viewed 1494 times

Dilbeek.jpg (86.95 KiB) Viewed 1492 times

[lmviterbo]

In Portugal, the team does as tigerpranke says, which is as we've been told to do long long time ago by the first coordinators. In fact, the system is prepared for this way of managing locations (and once you know how to use it, it's in fact a very good system).

There is only one completely correct entry under that city-profile:

Code: Select all

2006-09-26 01:45:51	 	Aarschot (3200)	 	50.9852	 	4.83446	 	45003	 	84

If we plotters don't assign any coordinates for any of the other locations, here's what happens:

• Locations under the same parent city-profile, even with a different name, but with the exact same postal code, will automatically assume the coords of the sibling. Example (notice that the name is mispelled):

  Code: Select all

  2006-09-26 01:45:51	 	Aarchot (3200)	 	0	 	0	 	9	 	0

  "Interpolated coordinates: 50.9852, 4.8345 (found sibling with exact zip code)" — so in practice those coords are correct if the plotters don't plot them.
• All other locations under the same parent city-profile (with different names, or different names and postal codes) will automatically assume the coords calculated as an average of all siblings. Notice that if we plotters plot only ONE sibling, the average is of course those correct coords. Examples:

  Code: Select all

  2012-01-06 17:18:17	 	Aarschot (32000)	 	0	 	0	 	2	 	0
  2014-12-03 22:28:23	 	Aatschot (32002)	 	0	 	0	 	2	 	0

  "Interpolated coordinates: 50.9852, 4.8345 (average of all siblings)" — so, again, in practice those coords will be correct if the plotters don't plot them.

Advantages of not giving coords to mistyped or (even partially) wrong locations:

1. Plotters will save a lot of time.
2. A cleaner database.
3. A warning system (if there is not a legion of plotters to correct every single entry and guess what the EBT user meant).
4. No guessing involved, so less errors by the plotters.

What happens when someone enters some note on something like:
City: Aarschot (Langdorp)
Postal code: B3201

The system assumes cities before postal codes (arguably on the assumption that there's less chance of someone messing up a city name than a number). So the first thing the system does is trying to guess what city-profile should this be under. If it "succeeds", it goes under the mentioned ID 414 (Aarschot, https://pt.eurobilltracker.com/profile/?city=414 on EBT, https://eurobilltracker.com/util/cityma ... b=5&id=414 on citymanager), without any coordinates to begin with. Then (in milliseconds, I suppose), it will calculate interpolated coordinates based on the other siblings under the same city-profile.

Now steps in a diligent plotter and tries to guess what the user meant. In this special hypothetical case, if you know the region, it's reasonably safe to assume that the user wanted Langdorp (3201). So you can do one of two things:

1. Move that location under Langdorp (ID 51989)
2. Deliberately ignore it

Note that in some cases it's not that straightforward to guess the intentions of the one who entered the notes. Here are some examples I found:

• Aarschot (3201) — the system put it under Aarschot; later on, some plotter assumed that 3201 would be correct and moved it under Langdorp.
• Gijmel (3201) — the system probably hasn't found any similar stuff and crated a new profile; later on, some plotter merged it under Langdorp.
• Aarschot (3202) — same as the first example above.

In all the above cases, in fact, I would say there is a high chance that the intentions were correctly guessed, because the official form of postal address in Belgium includes the municipality name but not the "populated place" (EBT's "city") name, and because that's also what maps say.

But then it looks like these criteria aren't consistent over the entire Belgium database. Here are two other examples:

• Walsbets (3401) — this was created in 2015; the system probably hasn't found anything similar and created a new profile; later on, some plotter gave it geocoords (lat/long).
• Landen (3401) — this had apparently been entered manually in the system in 2006; at the same time or later on, some plotter assigned it geocoords; but it was never moved under Walsbets (the closest "city" to Landen within 3401 zone). This move would arguably be equivalent to moving Aarschot (3201) under Langdorp (and not under the farther Wolfsdonk, also within the 3201 zone).

It's much easier to do all these moves in Belgium than in Portugal, but then it's too time-consuming and prone to more errors. The same with all the unnecessary plotting (assigning lat/long). If the plotters deliberately ignore mistyped or wrong locations, most of them will be placed correctly by the system, but if not there's a chance someone complains, and that's when we have the chance to educate EBT users to correct their data and help us keep a clean database.


Furthermore, there is no reason to use more than 3 decimal digits for locations in Belgium — assuming they all encompass an area on the same scale of magnitude as Aarschot (3200). On places with 1 km², it's completely reasonable to use 3 decimal digits. In this case, "50.985, 4.834" would fit perfectly (the distance between this and the misleading "precise" 50.9852, 4.83446 is in fact about 40 meters only). Precision of 4 (or 5) decimal digits should be reserved for complex systems like the Portuguese one, where parts of blocks and even individual buildings may have unique postal codes. There is no harm in assigning these "accurate" coords, except that they are misleading, possibly making users think that the precision is needed.


On a last note: there was nothing wrong with Aarschot's geocoords, in fact — I had checked the city profile's coords after Burdie did (and didn't change anything because Burdie had done a good job). So the only reason for the dot being shown on the sea was a cache problem, meaning the old coords were still cached, that is, in memory. Sometimes, it's a matter of minutes for this to be automatically fixed, sometimes it takes longer than that.


TL; DR: Only completely correct location entries (city + postal code) should be manually assigned geocoords (lat/long), the rest of it will be most likely be automatically corrected by the system. When some location goes wrong and some EBT user complains, there's a chance to correct their errors.

[negative]

missing DOTs:

Budapest 47.407197, 19.018382
http://lt.eurobilltracker.com/notes/?id=161761730

Budapest 47.492838, 19.127817
http://lt.eurobilltracker.com/notes/?id=161761771

[tigerpranke]

missing DOTs:

Budapest 47.407197, 19.018382
http://lt.eurobilltracker.com/notes/?id=161761730

Budapest 47.492838, 19.127817
http://lt.eurobilltracker.com/notes/?id=161761771

done.

[negative]

missing DOT:
Vaiguva
55.701742, 22.751760
http://lt.eurobilltracker.com/notes/?id=162230298

[Burdie]

missing DOT:
Vaiguva
55.701742, 22.751760
http://lt.eurobilltracker.com/notes/?id=162230298

done, I don't know if there is a City Manager who is taking care of Lithuania.

[Fons]

I just noticed that some merged the notes from 4909 Oosterhout (71403) with Oosteind (71383).
Usually these mergings are a very good thing. But not in this case. There are mostly ans' notes. And she actually got most of these notes in Oosterhout (71403).
Could someone undo this merging?

[Burdie]

I just noticed that some merged the notes from 4909 Oosterhout (71403) with Oosteind (71383).
Usually these mergings are a very good thing. But not in this case. There are mostly ans' notes. And she actually got most of these notes in Oosterhout (71403).
Could someone undo this merging?

I think it was me.
(Rest in Dutch)
Ik ben hier van de Postcode uitgegaan. 4900 tot 4908 is Oosterhout 4909 is Oosteind (Gemeente Oosterhout) Om een dot op de juiste plaats te zetten naar aanleiding van plaatsnaam en postcode dan kom ik uit in Oosteind. Ik heb ook volledige postcodes met de naam Oosterhout overgeplaatst. Deze kwamen uit op straten in Oosteind.
Mijn gedachte hierachter is: Oosteind is Oosterhout. Ik kan de dot plaatsen waar het hoord (volgens postcode en naam) maar als ik dat doe dan moet ik ze overhevelen naar Oosteind. want Oosterhout is niet (altijd) Oosteind.
Je hebt inderdaad gelijk dat vele (516473) biljetten Oosterhout (4909) hebben en dit zijn Ans' notes.
Zeg maar wat te doen, ik ben voor rede vatbaar

[vermeer]

Oosteind is a City in Flag for Oosterhout Oosterhout, Noord-Brabant, Netherlands.
Hits involving Oosteind: 3.712
Notes: 517.611
Hit ratio: 1 : 139,44

Municipality Oosterhout
1 Flag for Netherlands Oosteind 517.611
2 Flag for Netherlands Oosterhout 175.020
3 Flag for Netherlands Dorst 3.316
4 Flag for Netherlands Den Hout 112

I cannot imagine that Oosteind has that much notes. Compared with Oosterhout (city) it has nothing to offer.

https://en.eurobilltracker.com/profile/ ... city=71383

[Fons]

Zeg maar wat te doen, ik ben voor rede vatbaar

I send you a PM

[de*lerger]

My trip to Greece left me with some dotless notes:

Zarakes 38.3032, 024.1921
Oktonia 38.5257, 024.1635
Kokkinoekklisies 38.5547, 024.1142 (also seen as Kokinoeklisies)
Strofilia 38.8203, 023.4094
Nees Pagases 39.3268, 022.9267
Pelasgia 38.9478, 022.8400
Egira 38.1482, 022.3558

These two seem to be misplaced. A dot is shown, but they don't appear on my map:

Patras (26333) should be in the southern Patras dot
Loutraki 37.9747, 022.9800

And finally Agia Marina (ID 219015) can be merged with Agia Marina (ID 218025)

[Burdie]

@de*lerger I did made a start in Greece, but for me it was very to see with Municiplaity the places belong.
My keybord couldn't type the greek names and I could not find the greece name somewhere on the internet so that I could copy and past it.

I hope someone else could help you

[lmviterbo]

I might be able to try the Greek ones if there's no one with better knowledge of Greece, but anyway not before next week.