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
- 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
Advantages of
not giving coords to mistyped or (even partially) wrong locations:
- Plotters will save a lot of time.
- A cleaner database.
- A warning system (if there is not a legion of plotters to correct every single entry and guess what the EBT user meant).
- 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:
- Move that location under Langdorp (ID 51989)
- 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.
Aarschot coordinates is not fixing. Wrong postcodes or typos shouldn't get coordinates.
Budapest 47.407197, 19.018382Vaiguva
