Re: [OSM-talk] OpenStreetMap Carto release v4.17.0
Good morning Daniel, There is a relatively new leisure or sport activity, the so called "street workout". I mapped couple of new street workout grounds as leisrure=fitness_station, sport=exercise, which could be seen with the HD images via these links: https://www.openstreetmap.org/way/631600472 https://www.openstreetmap.org/way/648509242 The OSM icon is a running man, but it does not reflect well the nature of this activity. It is possible to search Youtube on the text - "street workout" (or "ghetto workout") to see what it looks like in reality, in order to draw a new icon. Or maybe even a special tag? I am not sure if it is a problem, however this sport becomes popular, there are competitions. With best regards, Oleksiy On 26.11.18 02:37, Daniel Koć wrote: ... what problems are the most visible? ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Carto release v4.17.0
> BTW: what do you consider to be a progress here? What do you like the > most in recent changes and maybe what problems are the most visible? The sing ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Carto release v4.17.0
W dniu 25.11.2018 o 21:03, EthnicFood IsGreat pisze: > >> many thanks for maintaining Carto. It's great to see such constant >> progress there. > Ditto! > > Mark Thanks guys, good to hear your support! Currently we have few good people involved, doing a lot of work and the project is once again a teamwork (including talented icon designer who just does not try coding). If someone would like to try coding and maybe fixing some issues, it would be very welcome, because the team is small and there are still hundreds of open tickets. BTW: what do you consider to be a progress here? What do you like the most in recent changes and maybe what problems are the most visible? -- "Excuse me, I have some growing up to do" [P. Gabriel] ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Distribution of OSM ids could be much more useful!
Sorry messed up with interface, my reply was to Paul Norman but I didn't get his message so replied to a wrong email. I mentionned Permanent id because OSM anyway failed to implement it or didn't want to have it with sequential id. Best Regards, Victor On Sun, 25 Nov 2018 at 16:13, Tomas Straupis wrote: > Could you ealborate more on why you mention permanent id here? I see your > idea, but do not understand how it is connected to permanent id problem. > > There were some tests done regarding permanent id in Lithuania, but those > were regarding places of interest. > > If this has something in common, I could share some ideas and > observations, so that they do not now go in vain. Maybe somebody would like > to continue research, as this is quite an important thing to OSM. > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Distribution of OSM ids could be much more useful!
Yes, I threw the idea slightly unprepared to create a discussion. May be it shouldn't be that revolutionary as using 30 bits for geo-location index but *16 bits *wouldn't change much. As I see, we are talking *density vs geo-index.* I understand, your point that most of (or some) software is built to optimize density but it should be able to take advantage from geo-index as well. > 33 bits of ids will mean 56-64-bit space for geo-index cache (wouldn't fit operating memory) As of today we are approaching 33 bits and we may never approach 36 bits. Though to build a geolocation cache we need to associate each id at least with its location i.e. int representing a tile. So we need to add to 33 bits - 30 or 32 bits and we end up around 64 bits, so it is almost impossible to keep a geo index in the memory. The operation of extraction is the most popular in OSM and there it could benefit the most i.e. iterating over Way nodes you can immediately say if it is valuable or not for your dataset which might fit the operating memory well. By the second run you can combine the ways you are interested with with the nodes. > Z-curve locality I don't see any problem with locality of Z-curve cause it would not be used in any algorithm I see. The algorithm would build Z-tiles index which are interested for data set extraction. >Density issue, how many bits is the best to store Of course, we could write an algorithm and find the best-ratio between id-distribution and bits allocated for geo-index. I would try to speculate with 16 bits. If we take only 16 bits, the most dense area I would see as Munich and its suburbs (8th tile zoom). As I see that tile takes around *60 MB in osm.pbf*. And it brings roughly 5 000 000 - 10 000 000 ids and it is *23 extra bits. *So we could safely assume that we will stay in *26 bits* and 16 + 26 = *42 bits *which falls under your assumption of dense software, I guess. The most important to say that difference between 42 and 34 bits is not huge for software at all cause there is always alignment by 8 bits. BTW: I could imagine that working with Whole planet is different use case where you need to maintain all global indexes and so on. Of course, by taking extra work on OSM DB and OSM API, it should help a lot 3rd party apps which don't process whole planet. Best Regards, Victor On 25 Nov 2018 06:36:39 -0800, Paul Norman wrote > It would be terrible for most software that I am aware of that can > process the full planet. Current assumptions about density would be > broken, vastly inflating memory usage and slowing down processing. > > The benefits aren't great as I see them. Using a z-order curve encoded > in the first 30 bits will help cache locality, but like all z-order > curves, it doesn't guarantee that two nearby places in 2d space have > nearby places on the curve. This means that an implementation still > needs to be able to search through the nodes for nearby ones. > > Two other problems come to mind. The first of these is implementation. > IDs are a PostgreSQL bigserial, and to write something custom that > assigns IDs based on location would be difficult as it would need to get > MVCC right. The second is the number of bits. Some software is limited > to 53-59 bits, and other to 63 bits. We're using about 75% of 33 bits > right now. > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Carto release v4.17.0
Date: Sun, 25 Nov 2018 10:57:47 +0100 From: Johannes Singler To: talk@openstreetmap.org Subject: Re: [OSM-talk] OpenStreetMap Carto release v4.17.0 Hi Daniel, many thanks for maintaining Carto. It's great to see such constant progress there. Johannes Am 23.11.2018 um 01:55 schrieb Daniel Koć: Dear all, Today, v4.17.0 of the OpenStreetMap Carto stylesheet (the default stylesheet on the OSM website) has been released. Once changes are deployed on the openstreetmap.org it will take couple of days before all tiles show the new rendering. Changes include - Showing natural areas from z5 - Cleaning up medium zoom rendering, including: - Making societal amenities look like residential on z10-z12 - Rendering motorway junction names from z13 instead of z12 - Dropping buildings up to z13 instead of z13 - Correctly dropping minor waterways from z13 - Rendering intermittent streams/ditches/drains from z15 - Reducing lightening of tramways - Rendering religious landuse and place of worship lighter - Adding text-repeat-distance for highway names - Rendering dots for gastronomy objects on z17 - Adding icons for memorial subtags - Rendering man_made=telescope - Rendering amenity=internet_cafe - Adding icon for amenity=public_bookcase - Adding icons for barrier=cattle_grid and barrier=stile - Adding icon for leisure=fishing - Rendering entrance for underground parking - Rendering basin=detention/infiltration as intermittent water - Tweaking outline of swimming pools and rendering it from z17 - Moving danger_area into landuse-overlay - Buildings code rewrite Thanks to all the contributors for this release including jeisenbe, a new contributor. For a full list of commits, see https://github.com/gravitystorm/openstreetmap-carto/compare/v4.16.0...v4.17.0 As always, we welcome any bug reports at https://github.com/gravitystorm/openstreetmap-carto/issues Ditto! Mark ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] weeklyOSM #435 2018-11-13-2018-11-19
The weekly round-up of OSM news, issue # 435, is now available online in English, giving as always a summary of all things happening in the openstreetmap world: http://www.weeklyosm.eu/en/archives/11010/ Enjoy! weeklyOSM? who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages where?: https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Distribution of OSM ids could be much more useful!
If you agree that tile id is assigned only upon creation, then you don't have to remove the history for moved or existing nodes. Also, Google S2 gives much more standard globe locality index, if you need a look up table. You can try getting a pull request with the change through railsport and cgimap maintainers though, as they are the only people limiting pace of openstreetmap api development :) On Sun, Nov 25, 2018 at 4:53 PM Victor Shcherb wrote: > Hi All, > > As we know OSM id for nodes exceeded long time ago 2^32 and keep growing > on the other hand the ids itself are pretty useless because they don't > represent history good enough and also they couldn't implement principle of > Permanent ID (https://wiki.openstreetmap.org/wiki/Permanent_ID). > > I suggest to discuss geometrical value of OSM id per node. Of course there > is ongoing discussion to attach OSM nodes to ways, so the number of nodes > will decrease dramatically but that's a long-mid term strategy. Much easier > is to give some value to OSM ID. > > PROPOSAL. Dedicate 30 bits of OSM ids to the quadrant of the Globe (per > square radiant) i.e. last *30 bits *of the ID could represent *15th zoom > of globe radiant tile *(not Mercatoor projection tiles). > > What's useful. > 1. Programs to import OSM could process it much faster cause id in the > ways could indicate where physically the way is located. > 2. Programs that store IDs could store much more compressed i.e. OsmAnd > maps could benefit for storing maps in QuadTile structure and keep only > part of id attached to QuadTile > 3. It is a step forward to compress the data and have formats for faster > processing and better storage. > 4. Probably something more? > > Why it is easy to implement. > - Doesn't require to change anything in the schema and in the tools > - Most likely doesn't require to change any editor cause the changes could > be postprocessed by the changeset commiter. > - *Backward compatible!* Old ids before the given number could stay the > same for a while. > > Challenges / Objections. > - If you move a node from its original tile the history will be lost and > id will be changed (I doubt it is a strong objection cause information > could be partially / visually restored from changeset history). > - The uploading changeset from editor could differ from result changeset > stored in OSM API. > > What do you think? > > Best Regards, > Victor > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk > -- Darafei Praliaskouski Support me: http://patreon.com/komzpa ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Distribution of OSM ids could be much more useful!
Could you ealborate more on why you mention permanent id here? I see your idea, but do not understand how it is connected to permanent id problem. There were some tests done regarding permanent id in Lithuania, but those were regarding places of interest. If this has something in common, I could share some ideas and observations, so that they do not now go in vain. Maybe somebody would like to continue research, as this is quite an important thing to OSM. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Distribution of OSM ids could be much more useful!
Am 25.11.18 um 15:36 schrieb Paul Norman: > On 2018-11-25 5:50 AM, Victor Shcherb wrote: >> What do you think? > > It would be terrible for most software that I am aware of that can > process the full planet. Current assumptions about density would be > broken, vastly inflating memory usage and slowing down processing. > +1 Absolutely agree here. It would be pretty bad for dense ids in libosmium as it would cause significantly higher memory consumption. Large ids would immediately cause issues on Overpass API as well, for which we already have an open issue: https://github.com/drolbr/Overpass-API/issues/465, just to name two more examples. -- ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Distribution of OSM ids could be much more useful!
On 2018-11-25 5:50 AM, Victor Shcherb wrote: What do you think? It would be terrible for most software that I am aware of that can process the full planet. Current assumptions about density would be broken, vastly inflating memory usage and slowing down processing. The benefits aren't great as I see them. Using a z-order curve encoded in the first 30 bits will help cache locality, but like all z-order curves, it doesn't guarantee that two nearby places in 2d space have nearby places on the curve. This means that an implementation still needs to be able to search through the nodes for nearby ones. Two other problems come to mind. The first of these is implementation. IDs are a PostgreSQL bigserial, and to write something custom that assigns IDs based on location would be difficult as it would need to get MVCC right. The second is the number of bits. Some software is limited to 53-59 bits, and other to 63 bits. We're using about 75% of 33 bits right now. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Distribution of OSM ids could be much more useful!
Hi All, As we know OSM id for nodes exceeded long time ago 2^32 and keep growing on the other hand the ids itself are pretty useless because they don't represent history good enough and also they couldn't implement principle of Permanent ID (https://wiki.openstreetmap.org/wiki/Permanent_ID). I suggest to discuss geometrical value of OSM id per node. Of course there is ongoing discussion to attach OSM nodes to ways, so the number of nodes will decrease dramatically but that's a long-mid term strategy. Much easier is to give some value to OSM ID. PROPOSAL. Dedicate 30 bits of OSM ids to the quadrant of the Globe (per square radiant) i.e. last *30 bits *of the ID could represent *15th zoom of globe radiant tile *(not Mercatoor projection tiles). What's useful. 1. Programs to import OSM could process it much faster cause id in the ways could indicate where physically the way is located. 2. Programs that store IDs could store much more compressed i.e. OsmAnd maps could benefit for storing maps in QuadTile structure and keep only part of id attached to QuadTile 3. It is a step forward to compress the data and have formats for faster processing and better storage. 4. Probably something more? Why it is easy to implement. - Doesn't require to change anything in the schema and in the tools - Most likely doesn't require to change any editor cause the changes could be postprocessed by the changeset commiter. - *Backward compatible!* Old ids before the given number could stay the same for a while. Challenges / Objections. - If you move a node from its original tile the history will be lost and id will be changed (I doubt it is a strong objection cause information could be partially / visually restored from changeset history). - The uploading changeset from editor could differ from result changeset stored in OSM API. What do you think? Best Regards, Victor ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Carto release v4.17.0
Hi Daniel, many thanks for maintaining Carto. It's great to see such constant progress there. Johannes Am 23.11.2018 um 01:55 schrieb Daniel Koć: Dear all, Today, v4.17.0 of the OpenStreetMap Carto stylesheet (the default stylesheet on the OSM website) has been released. Once changes are deployed on the openstreetmap.org it will take couple of days before all tiles show the new rendering. Changes include - Showing natural areas from z5 - Cleaning up medium zoom rendering, including: - Making societal amenities look like residential on z10-z12 - Rendering motorway junction names from z13 instead of z12 - Dropping buildings up to z13 instead of z13 - Correctly dropping minor waterways from z13 - Rendering intermittent streams/ditches/drains from z15 - Reducing lightening of tramways - Rendering religious landuse and place of worship lighter - Adding text-repeat-distance for highway names - Rendering dots for gastronomy objects on z17 - Adding icons for memorial subtags - Rendering man_made=telescope - Rendering amenity=internet_cafe - Adding icon for amenity=public_bookcase - Adding icons for barrier=cattle_grid and barrier=stile - Adding icon for leisure=fishing - Rendering entrance for underground parking - Rendering basin=detention/infiltration as intermittent water - Tweaking outline of swimming pools and rendering it from z17 - Moving danger_area into landuse-overlay - Buildings code rewrite Thanks to all the contributors for this release including jeisenbe, a new contributor. For a full list of commits, see https://github.com/gravitystorm/openstreetmap-carto/compare/v4.16.0...v4.17.0 As always, we welcome any bug reports at https://github.com/gravitystorm/openstreetmap-carto/issues ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
