Re: [OSM-dev] Why is ford=yes not rendered in the default style?
Dave F. wrote on 27.11.2015 15:44: > On 27/11/2015 02:50, Daniel Koć wrote: >> It would be impossible to render every tag (even if we just talk about >> those with Wiki page), but unfortunately we were not able to agree >> even on the most general rules: >> https://github.com/gravitystorm/openstreetmap-carto/issues/1630 > We're not talking about 'every' tag. It's about one entity that is > *already* rendered. To benefit the OSM database It was agreed to change > to a new tag. For the past couple of years Mapnik carto has failed to > change over. >>>Am I right in thinking the style file has been updated only once in >>>over two years & that was just to delete comments? >> There's even a rough plan for so called "database reload": > Ah, It's a plan not a system :-) >> https://github.com/gravitystorm/openstreetmap-carto/issues/1504 > What is the 'database' that's referred to? Presumably not the main OSM one. All changes in the main OSM database (containing all data) are copied in a special rendering database for performance reason. This transformation had a white list of tags (highway=*, amenity=*, natural=*, landuse=*,...) which is available for rendering. Perhaps this was a bad idea, but this is the status quo, since many years. Changing this white list to a more open infrastructure requires a complete reload of the rendering database which needs a few days and many preparations. No one had the time to change that in their free time (no one is paid for managing the servers and software!) till now. >> however it seems it's not being worked on and Paul is not happy with >> such things, because he feels it will basically enable rendering more >> items (contrary to his view on the style): >> https://github.com/gravitystorm/openstreetmap-carto/issues/1975#issuecomment-157134906 >> > Whatever his opinions are, the process used by OSM carto shouldn't > prevent an previously agreed/supported tag from being quickly added & > rendered. Exact that is the reason the developer wants to get rid of the white-list-only approach. This is the list of issues waiting for the change of the infrastructure: https://github.com/gravitystorm/openstreetmap-carto/issues?q=is%3Aopen+is%3Aissue+milestone%3A%223.x+-+Needs+upgrade+to+openstreetmap-carto.style%22 -- regards Holger ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Why is ford=yes not rendered in the default style?
On 27/11/2015 02:50, Daniel Koć wrote: W dniu 27.11.2015 1:47, Dave F. napisał(a): However I still think there's something wrong with a system that takes years to render an almost universal accepted replacement tag for a deprecated one that was previously rendered. In my opinion there's hardly a "system" in OSM, because even core subprojects are rather disconnected (for example no common presets for JOSM and iD). Maybe the rendering 'procedure' would be a better description. It would be impossible to render every tag (even if we just talk about those with Wiki page), but unfortunately we were not able to agree even on the most general rules: https://github.com/gravitystorm/openstreetmap-carto/issues/1630 We're not talking about 'every' tag. It's about one entity that is *already* rendered. To benefit the OSM database It was agreed to change to a new tag. For the past couple of years Mapnik carto has failed to change over. Am I right in thinking the style file has been updated only once in over two years & that was just to delete comments? There's even a rough plan for so called "database reload": Ah, It's a plan not a system :-) https://github.com/gravitystorm/openstreetmap-carto/issues/1504 What is the 'database' that's referred to? Presumably not the main OSM one. however it seems it's not being worked on and Paul is not happy with such things, because he feels it will basically enable rendering more items (contrary to his view on the style): https://github.com/gravitystorm/openstreetmap-carto/issues/1975#issuecomment-157134906 Whatever his opinions are, the process used by OSM carto shouldn't prevent an previously agreed/supported tag from being quickly added & rendered. Cheers Dave F. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Why is ford=yes not rendered in the default style?
On 27/11/15 09:44, Gerd Petermann wrote: Do we have a database design that stores each OSM element with numerous columns for all possible supported attributes? I guess that would explain why there are technical limits. Yes the current schema has one column for each tag, but obviously limited to certain tags chosen when the database is created. So there is a highway column, a waterway column, a name column and so on, which the value being the value of the tag in question, or null if the object doesn't have that tag. So it's obviously quite wasteful to create hundreds of columns for relatively rare tags that will be null for most records. Hence the reason the tools how have the option to store some or all tags in a single hstore column - that's basically a column whose value is a hash of keys and values. You can read more here: https://github.com/openstreetmap/osm2pgsql/blob/master/docs/usage.md#hstore So the idea is that at the next reload some of the rarer key values would be moved into an hstore column, and that extra tags could be included in that set. It does need some matching changes to the style sheet though, as the syntax for SQL queries to select on values in the hstore will be different to the condition for selecting on a normal column. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Why is ford=yes not rendered in the default style?
On 27/11/15 08:13, Gerd Petermann wrote: - Whatever DB design is used now is considered to be unable to store more attributes without changing the DB design. No that's not true, More attributes can be added, but only when a full reload is done. I mean we could add the extra columns to the existing database, but they would only get populated for changes made after that date and wouldn't be backfilled with values for existing objects. In theory somebody could write something to read the planet and backfill those columns but I don't believe it exists currently. - it was decided that the new design has to use hstore No, it was decided that it probably makes sense to use hstore for the less common attributes because it means you're not creating lots of columns that are mostly empty. Whether hstore or new columns are used doesn't really matter - in either case adding the column without a reload would mean the data was missing for existing objects. - nobody has made progress understanding how hstore works since then. I have no idea why you think this. We understand perfectly well how it works and plenty of people have stylesheets using it. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Why is ford=yes not rendered in the default style?
Mateusz Konieczny-2 wrote > On Thu, 26 Nov 2015 03:24:25 -0700 (MST) > Gerd Petermann < > gpetermann_muenchen@ > > wrote: > >> OK, thanks for the quick feedback. The term "technically not possible" >> seems to mean that I cannot help to fix it ? > > Anybody can help, but it requires some additional knowledge. For start > "There's nothing published about moving a style to hstore and making > schema choices based on data." (quoting > https://github.com/gravitystorm/openstreetmap-carto/issues/1975 ). > > ___ > dev mailing list > dev@ > https://lists.openstreetmap.org/listinfo/dev Well, I have nearly no knowledge regarding the underlying database system (DB) PostgreSQL, but I am eager to find out why the rendering of accepted attributes require changes in the system architecture. My understanding so far: - ford=yes is only one of many attributes which are well documented but not rendered. - Whatever DB design is used now is considered to be unable to store more attributes without changing the DB design. - it was decided that the new design has to use hstore - nobody has made progress understanding how hstore works since then. Maybe it is time to go back one step and ask if hstore is the only possible solution? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Why-is-ford-yes-not-rendered-in-the-default-style-tp5861038p5861104.html Sent from the Developer Discussion mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev