4 ms·
Author states: >And that’s the point, rules and complexity have completely unknowable downsides. Downsides like the destruction of the whole project. With each
by zigzag312 4y ago
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 standardization can actually reduce complexity and really doesn't cause a "destruction of the whole project".
As a counterpoint, too much flexibility can also increase complexity. For example, without defined rules, 5.6.2022 can mean 5. June 2022 or 6. May 2022. Nor user, nor parser can know for sure what it means, if standard isn't defined. This kind of flexibility certainly isn't fun.
Example from OSM wiki for "Key:source:date":
> There is no standing recommendation as to the date format to be used. However, the international standard ISO 8601 appears to be followed by 9 of the top 10 values for this tag. The ISO 8601 basic date format is YYYY-MM-DD.
https://wiki.openstreetmap.org/wiki/Key:source:date https://wiki.openstreetmap.org/wiki/Key:source:date
Just define some essential standards. It won't lead to destruction of the project!
And while you are making breaking changes, please fix the 'way' element. Maps are big. Storing points in ways as 64bit node-ids, while coordinates in nodes are also 64-bit (32bit lon and 32bit lat), just leads to wasted space and wasted processing time. There are billions of these nodes and nearly all of these nodes don't have tags, just coordinates. There is no upside for this level of indirection. And in case tags are needed for a point, this can already be solved with a separate node and a 'relation' element.
OSM data format could certainly be improved and it would benefit end users, as better tools/apps could be made more quickly and easily.
- atoav 4y agoThe 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 every corner. I think a lot of that complexity can (and should!) live in the tools themselves. Who cares about a date format, when the tool that creates it offers a date picker or extracts the correct date from the meta data of an image? The date format in the backend should be fixed and then you should offer flexibility in the frontend for user input.
- Archelaos 4y ago> 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 March 44 BC in ISO-8601? A: -0043-03-13 Why? -- Ancient dates are typically given according to the Julian calendar excluding a year 0, but ISO-8601 uses a proleptic Gregorian calendar including a year 0.
- nvrspyx 4y agoThis 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.
- Archelaos 4y agoI had the Open Historical Map sub-project in mind, which currently supports only ISO-8601.[1] [1] https://wiki.openstreetmap.org/wiki/Open_Historical_Map/Tags#Dates:_Required_for_Rendering https://wiki.openstreetmap.org/wiki/Open_Historical_Map/Tags...
- netsharc 4y agoIn Java and Javascript, months are 0-based, so October is 9. Geez, imagine forcing people to write "October 15, 2019" as "2019-09-15"
- Archelaos 4y agoYeah, as it already is an imposition to use 10 for what is called "Month Eight" (from Lat.: octo = 8).
- BitwiseFool 4y ago
- joshxyz 4y agowhy not use the universal date format [1] that works for everyone? yyyy mm dd mm yyyy [1] https://twitter.com/dan_abramov/status/1447710863960551433 https://twitter.com/dan_abramov/status/1447710863960551433
- RcouF1uZ4gsC 4y agoIt actually doesn't work for Americans who write: mm dd yyyy
- magicalhippo 4y agoTrivially fixed by using mm dd yyyy mm dd mm yyyy.
- Grimburger 4y agoUnix 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.
- lovemenot 4y agoWhy 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.
- deathanatos 4y agohttps://en.wikipedia.org/wiki/Decimal_time#France https://en.wikipedia.org/wiki/Decimal_time#France
- misnome 4y agoAlong with most of the metric system, which they did somehow manage to persuade the rest of the world to use.