81–90 of 130 posts
Earlier quoted context omitted.
> so many tables ? There are various complaints about OSM data model but this is a new one to me. In OSM basically everything is mixed together and there is no real separation into layers. What you mean by "many tables"?
He probably means what the osm2pgsql import tool creates.
"many tables" is definitely osm2pgsql design decision
Earlier quoted context omitted.
Unix time is the real universal date format surely? It underpins basically everything in datetime database entries. The problem is that most people can't read that along with the French somehow never being able to convince the world to adopt decimal time.
Why make a good point and follow it with a bad joke which: both has a class of victim and does not work as a joke? Nobody has ever heard of "the French" undertaking such a project. And if it had ever happened, it would most surely have been a particular Academy or the like. Not the 65M people under your careless swipe.
Wasn't meant as some slight against the French, completely the opposite hey, honestly think they had the right idea, the rest of the world got it wrong...and... that's very much a minority opinion these days. Some things are just ingrained into everyone I guess.
I know it’s nothing to do with the main thrust of the article, but the author fundamentally misrepresents KYC. Know-your-customer is a facet of anti-money laundering and anti-corruption regulation. It has nothing to do with talking to users.
Perhaps an existing term was co-opted by financial legislation...
> The answer, as any product owner will tell you, is to get close to the customer. To talk to them. To understand them. To feel their pain. The {big short}:
> Deutsche Bank had a program it called KYC (Know Your Customer), which, while it didn't involve anything so radical as actually knowing their customers, did require them to meet their customers, in person, at least once.
Earlier quoted context omitted.
> The date format in the backend should be fixed and then you should offer flexibility in the frontend for user input. Agreed. However, it might be not so easy for historical dates, because doing it correctly requires great diligence on the part of the tool developer as well as from the user to choose the correct calendar system. For example: Q: What is the correct representation of the date of Caesar's death, 15 Mar…
This is a good point in a general sense, but I don't think it would be a problem in this particular case for the date some imported OSM data was sourced, which is similar to the "date accessed" for a website in a bibliography.
[1] https://wiki.openstreetmap.org/wiki/Open_Historical_Map/Tags...
Earlier quoted context omitted.
The date example is a good one. No one has fun by choosing their own date format. This is putting the burden of choice onto the user. They might like to think about some map stuff and now they have to think about data format stuff. Of course projects like these have to strike a balance between the strictest bureaucratic nightmare and such a structure so loose that people are overburdened by the available options at e…
> The date format in the backend should be fixed and then you should offer flexibility in the frontend for user input. Agreed. However, it might be not so easy for historical dates, because doing it correctly requires great diligence on the part of the tool developer as well as from the user to choose the correct calendar system. For example: Q: What is the correct representation of the date of Caesar's death, 15 Mar…
The claim that a dataset with billions of users has only dozens of people able/interested in doing data processing on it is a damning admission that the format is too hard to deal with
Slowly deprecate the nastiest parts of the old, as people get used to the new format.
Earlier quoted context omitted.
No one is suggesting throwing away OSM's data model completely. The current suggestion is basically "maybe we should think about a point release to properly address an ugly hack we invented in 2007".
Right? The emotion of the response seems completely out of scale to the ambition of the reform proposed. "Maybe polygons?"
What is currently on the table is simply a way to cleanly differentiate between closed ways that are polygons and actual closed ways. Example roundabout enclosing a park. The problem is that right now this relies on determining this from the tagging. This could well be implemented as a flag on the existing way type and not as an actual new datatype.
There is at this stage no intention to revamp the way how we model areas that are more complex than the single polygons from above, that is with multi-polygon relations.
The more controversial topic is giving OSM way objects partially or fully their own geometry.
The former would have for all practical purposes no noticeable contributor effect outside of geometry changes always creating new versions of ways, contrary to the current behaviour which can be somewhat puzzling for newbies.
The later would be quite drastic, but would provide more benefits for at least some kinds of processing, for others not, as then topology would have to be inferred.
In any case the 90% of the discussion on this topic fretting about tagging is completely misplaced as literally nobody is even remotely considering changing that.