Re: [OSM-dev] Why is ford=yes not rendered in the default style?

[Holger Jeromin]

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?

[Dave F.]

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?

[Tom Hughes]

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?

[Tom Hughes]

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?

[Gerd Petermann]

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

[OSM-dev] Why is ford=yes not rendered in the default style?

[Gerd Petermann]

Hi all,

I know we should not map for the renderer, but why is 
the deprecated and rarely used highway=ford
rendered with a nice icon on https://www.openstreetmap.org
while the much more often and documented 
ford=yes is not ?

Gerd



--
View this message in context: 
http://gis.19327.n5.nabble.com/Why-is-ford-yes-not-rendered-in-the-default-style-tp5861038.html
Sent from the Developer Discussion mailing list archive at Nabble.com.

___
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?

[Martin Koppenhoefer]

2015-11-26 10:57 GMT+01:00 Gerd Petermann :

> I know we should not map for the renderer, but why is
> the deprecated and rarely used highway=ford
> rendered with a nice icon on https://www.openstreetmap.org
> while the much more often and documented
> ford=yes is not ?
>


because currently in the rendering DB the highway key is available while
the ford key is not.

Cheers,
Martin
___
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?

[Christoph Hormann]

On Thursday 26 November 2015, Gerd Petermann wrote:
>
> I know we should not map for the renderer, but why is
> the deprecated and rarely used highway=ford
> rendered with a nice icon on https://www.openstreetmap.org
> while the much more often and documented
> ford=yes is not ?

Because the ford key is currently not in the rendering database.  See:

https://github.com/gravitystorm/openstreetmap-carto/issues/267


-- 
Christoph Hormann
http://www.imagico.de/

___
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?

[Holger Jeromin]

Gerd Petermann wrote on 26.11.2015 10:57:
> I know we should not map for the renderer, but why is 
> the deprecated and rarely used highway=ford
> rendered with a nice icon on https://www.openstreetmap.org
> while the much more often and documented 
> ford=yes is not ?

http://wiki.openstreetmap.org/wiki/Standard_tile_layer
links to
https://github.com/gravitystorm/openstreetmap-carto/issues
in the second sentence. Search there "ford" and you get:
https://github.com/gravitystorm/openstreetmap-carto/issues/267

Right now it is technically not possible, but will be in the future.

-- 
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?

[Gerd Petermann]

OK, thanks for the quick feedback. The term "technically not possible"
seems to mean that I cannot help to fix it ?

Gerd


Holger Jeromin wrote
> Gerd Petermann wrote on 26.11.2015 10:57:
>> I know we should not map for the renderer, but why is 
>> the deprecated and rarely used highway=ford
>> rendered with a nice icon on https://www.openstreetmap.org
>> while the much more often and documented 
>> ford=yes is not ?
> 
> http://wiki.openstreetmap.org/wiki/Standard_tile_layer
> links to
> https://github.com/gravitystorm/openstreetmap-carto/issues
> in the second sentence. Search there "ford" and you get:
> https://github.com/gravitystorm/openstreetmap-carto/issues/267
> 
> Right now it is technically not possible, but will be in the future.
> 
> -- 
> regards
> Holger
> 
> 
> ___
> dev mailing list

> dev@

> https://lists.openstreetmap.org/listinfo/dev





--
View this message in context: 
http://gis.19327.n5.nabble.com/Why-is-ford-yes-not-rendered-in-the-default-style-tp5861038p5861044.html
Sent from the Developer Discussion mailing list archive at Nabble.com.

___
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?

[Dave F.]

Hi

@Holger: Could you explain why it's "technically not possible"? It seems 
strange just this one node can't be rendered.



This icon was proposed & received general approval:
https://github.com/gravitystorm/openstreetmap-carto/issues/118#issuecomment-67555409 



I'm unsure why it's not gained favour with those who upgrade the carto. 
It's the most relevant idea I've seen so far. Waves for the water & 
lines to represent the way. There's no need to show cars as many (most?) 
fords are for non vehicular ways.


The current icon (on highway=ford only) shows a double headed arrow. 
Icons should be relevant to what they're trying to indicate I don't see 
the connection between arrows & fords. Nothing needs sizing or measuring 
& for obvious reasons, it can't be to indicate the flow direction.


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?

[Simon Poole]

Am 26.11.2015 um 13:20 schrieb Dave F.:
> Hi
>
> @Holger: Could you explain why it's "technically not possible"? It
> seems strange just this one node can't be rendered.
>
>
Because the rendering database doesn't contain the information and any
strategy to fix it requires a reimport of the database. So naturally
"technically not possible" is not really correct, it is simply dependent
on other things happening.



signature.asc
Description: OpenPGP digital signature
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [josm-dev] [OSM-dev] Why is ford=yes not rendered in the default style?

[Daniel Koć]

W dniu 27.11.2015 3:33, Daniel Koć napisał(a):

Sorry, it was just the accidential list name error.

--
"Завтра, завтра всё кончится!" [Ф. Достоевский]

___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev

Re: [josm-dev] [OSM-dev] Why is ford=yes not rendered in the default style?

[Daniel Koć]

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).


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


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":

https://github.com/gravitystorm/openstreetmap-carto/issues/1504

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

--
"Завтра, завтра всё кончится!" [Ф. Достоевский]

___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev