41–50 of 130 posts
I have been looking into improving kerb and traffic_signals data for some bboxen. It is daunting, and I figure I need to work backwards - try to find out what the accessibility map apps look for and use those pairs. If I know what target I am shooting for I guess it will be alright. This is like my first week looking into this and I hope to find these targets soon.
Earlier quoted context omitted.
I don't understand how this doesn't fit your use case. The tags are for different things, e.g. > for places where you can get larger amounts of "drinking water" for filling a fresh water holding tank, such as found on caravans, RVs and boats versus > a man-made construction providing access to water, supplied by centralized water distribution system (unlike in case of man_made=water_well [...]). The tag man_made=wate…
When features are sometimes tagged specifically and other times tagged more generically, it is impossible to get valid results. You either have to filter on the more specific tag (leaving out valid features) or include the generic tagged features (including features that should not be).
Earlier quoted context omitted.
why not use the universal date format [1] that works for everyone? yyyy mm dd mm yyyy [1] https://twitter.com/dan_abramov/status/1447710863960551433
It actually doesn't work for Americans who write: mm dd yyyy
Heh, their data model is 99% of the reason why I don't use OSM. It's scattered all over the place with so many tables ! It's such a nice project, but damn is it impossible to work with programmatically, let alone poke around it to discover what's all in there.
?
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"?
Author states: >And that’s the point, rules and complexity have completely unknowable downsides. Downsides like the destruction of the whole project. With each rule and added complexity you make the system less human and less fun. You make it a Computer Scientists rube goldberg machine while sterilizing it of all the joy of life. While too much rules and complexity can certainly be bad, some basic amount of standardi…
why not use the universal date format [1] that works for everyone? yyyy mm dd mm yyyy [1] https://twitter.com/dan_abramov/status/1447710863960551433
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.
Earlier quoted context omitted.
When features are sometimes tagged specifically and other times tagged more generically, it is impossible to get valid results. You either have to filter on the more specific tag (leaving out valid features) or include the generic tagged features (including features that should not be).
In this case it should not be a problem - listing mapped places suitable to get drinking water is quite reasonable here.
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.
Skip about 1/3 of the way down and the OSM article starts. “This is why bad design is everywhere...”
The entire article can be summed up as: “OSM stores maps as graphs, in flat files where each line is either a node, an ordered list of nodes, or metadata. The graph nodes can be arbitrarily ordered in OSM files, which leads to computational complexity when parsing them. This is not a bad thing, since it means that the spec for OSM files can be extremely simple, which makes it easy for people to contribute to OSM. Oth…
It could be an example of an author assuming a general audience already knows the insider information but then I don't know who the target audience really was. This is the kind of thing that probably should have been spelled out in the introduction, with a link to something like this:
The exact same argument that praises OSM's super flexible tagged node data model should also praise MS Excel for the number of things that can be achieved in the world of business with just a grid of boxes. Both have been hugely successful, and both have the same pile of downsides.
> Both have been hugely successful, and both have the same pile of downsides. Exactly. And the solution should not be to throw away spreadsheets completely and turn them into relational databases, but to create new tools to alleviate the downsides and reduce their impact (possible by exporting the spreadsheet information into a relational database, but without taking away the user's option to continue working with it…