[OSM-talk] Proposed changes in rendering of diplomatic offices

[Daniel Koć]

Hi,

There is a proposition to change rendering of diplomatic offices on OSM
Carto style (which is used for generating default map layer on OSM.org).
On the one hand it introduces flag symbols for a new tagging, but on the
other it would immediately stop rendering old, deprecated tag
(amenity=embassy):

https://github.com/gravitystorm/openstreetmap-carto/pull/4168

My concern is that such change would invite automated mass edits,
because half of these objects still carry the old tag, which is a lot
for such common and well known feature IMO:

https://taghistory.raifer.tech/#***/amenity/embassy&***/office/diplomatic

I think it's better for example to wait until the old tagging will pass
much lower limit (I propose 2k - the lower amount we consider worth
rendering in most of the cases) or just add new icons without removing
rendering for the old tag (it sholud be removed when it drops to a low
level).

What solution would you propose there?


-- 
"Holy mother forking shirt balls!" [E. Shellstrop]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Tagging Governance

[Daniel Koć]

W dniu 12.09.2019 o 07:02, Roland Olbricht pisze:
> > Changing to a github-like system of version management
>
> I thought of Git, not Github.
>
> This is an important distinction: Git is as decentralized as possible -
> whenever one works with a repo one gets the full data and history of the
> project to the local disk drive.


There is also GitHub-like service called Gitlab (with Community Edition
on a free license to be deployed on your own server), which is quite
popular option for managing Git projects, see:

https://en.wikipedia.org/wiki/GitLab


Since we talk here about iD editor design choices, I also wanted to
mention OSM Carto (default map style which I'm involved in) as one of
the important tools related to tagging. There are no simple relations
between tagging and rendering department, for example lack of rendering
some objects does not stop people from tagging them, but it certainly
influences their choices in some way.

Our team is pretty conservative in that regard - not only tagging has to
be documented on wiki and the numbers should be substantial, but if
there is one scheme, there's a resistance to deploy any other scheme
which would duplicate it, which hinders the usage of any redesigned
schemes (public transport comes to mind for example). Over the time the
problem of scheme transitions will certainly go higher, so it's good to
think about how should it be handled by rendering.


BTW: Is there a chance to record and publish the discussion on the web?
Currently it looks like it won't be recorded, but even unofficial
recording done by participants would be interesting to me:

https://2019.stateofthemap.org/sessions/PPTHFQ/


-- 

"Pojechałam truizmem, ale mogę, bo jestem trochę pierdołą" [P. Potocka]



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] OpenStreetMap Carto release v4.19.0

[Daniel Koć]

Dear all,

Today, v4.19.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
- Adding rendering for boundary=protected_area (#3509)
- Nature reserve boundaries revision (#3574)
- Adding support of amenity=vending_machine (#3601)
- Adding more barrier icons (#3602)
- Changing allotments color and adding outline (#3625)
- Reducing priority of tourism=attraction and rendering from z17 (#3603)
- Changing tourism outline color (#3582)
- Making country borders thicker at z8 and z9 (#3563)
- Rendering parking from z14 (#3612)
- Starting to render most patterns at z13 instead of z14 (#3610)
- Changing zoom level and text size for place=hamlet (#3626)
- Rendering airport gate refs black instead of purple (#3620)
- Updating zoom levels by height for masts, towers and telescopes (#3536)
- Hiding underground parking (#3600)
- Rendering ref of minor roads more than once (#3627)
- Adjusting width of highway=construction (#3580)
- Selecting only motorway_link to tertiary_link as link (#3567)
- Reducing tertiary-link width (#3570)
- Changing certain amenity icons to grey (#3586)
- Converting springs to use ST_PointOnSurface and reformatting SQL (#3233)
- Adding "religious-icon" as color variable for #00 (#3642)
- Adding "barrier-icon" color variable in #3f3f3f for barriers (#3643)
- Fixing inconsistency of leisure=ice_rink (#3598)
- Fixing label opacity for tourism features (#3616)
- Reverting lowzoom nobuilding test change (#3622)
- Removing trailing whitespace (#3637)

Thanks to all the contributors for this release.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.18.0...v4.19.0

As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues

-- 
"Excuse me, I have some growing up to do" [P. Gabriel]



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] OpenStreetMap Carto release v4.18.0

[Daniel Koć]

Dear all,

Today, v4.18.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


- Adding rendering for healthcare tag scheme
  - Changing hospital icon
  - Changing healthcare color to red
  - Changing natural=scrub color
  - Changing landuse=allotments color and pattern
- Adding rendering for natural=cape
- Rendering leisure=ice_rink
- Adding rendering for man_made=crane
- Adding icons for shop=fabric and shop=carpet
- Updating icons for amenity=arts_centre, leisure=slipway,
amenity=restaurant/amenity=food_court and
man_made=storage_tank/man_made=silo
- Using dedicated icon for artwork_type=bust
- Rendering railway pattern on z12
- Showing labels of big states (like Alaska)
- Moving railway=tram_stop and station=subway later
- Adding rendering for more private POIs
- Removing smoothing in leisure=track and attraction=water_slide
- Using subway bridge style for subway construction bridges
- Rendering wind turbines names and other tweaks
- Changing man_made gray and text color, making text-dy uniform
- Small documentation and code fixes

Thanks to all the contributors for this release including tpetillon, a
new contributor.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.17.0...v4.18.0

As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues

-- 
"I see dead people" [Sixth Sense]





___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [Osmf-talk] Candidate's views? Re: Board decision on Crimea complaint

[Daniel Koć]

W dniu 11.12.2018 o 14:59, Imre Samu pisze:
> Imho:  there are other core values
 
> So we need to find a global optimum - and it is not easy.


I agree. Thanks for checking our foundations. In day to day operations
it's not possible to know every rule in OSM and it's not even needed,
since some common rules of thumb are enough, but it's important to
really check it when discussing rules.


> TLDR:  We need focusing for the customizable vector tiles for the next
> year!    (  Less community fighting - more working on the real
> problems!  )


I hope there will be something for a start in the coming weeks:

https://github.com/openstreetmap/operations/issues/214#issuecomment-432002876


-- 
"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] Board decision on Crimea complaint

[Daniel Koć]

W dniu 11.12.2018 o 13:26, Christoph Hormann pisze:
> On Tuesday 11 December 2018, Martin Koppenhoefer wrote:
>> That’s why we need a method in OSM to say which countries recognize a
>> country/border, as it seems the most objective representation.
> Which would mean the end of OSM verifiability as intersubjective 
> verifiability based on observations in the real world in favor of 
> Wikipedia verifiability based on 'reliable sources'.


I have no clear answer how to solve borders problem, but that sounds
like FUD for me (using emotionally loaded claims not backed by evidence
to push or block something) and I'm against this kind of arguing. OSM is
not "all or nothing" game.

For example I don't believe "name:en=Crimean Peninsula" is observable in
this place, but I don't think anybody would complain against it, because
we already do rely on some sources other than real world (meant as a
ground truth). And that did not end other ways of verification yet.


-- 
"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] OpenStreetMap Carto release v4.17.0

[Daniel Koć]

W dniu 26.11.2018 o 09:50, Martin Koppenhoefer pisze:
> Am Mo., 26. Nov. 2018 um 01:40 Uhr schrieb Daniel Koć  <mailto:daniel@ko%C4%87.pl>>:
>
>
> 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?
>
>
>
> dropping buildings from z13 is really a pity, I would have liked to
> see them back on z12.


My intention was rather to hear about some general trends, since there's
no place that we can hear about. It usually ends up discussing single
cases, especially problems. We deal with it all the time and of course
this is the core of our work, but it does not help to think what could
be done in the future and what are general impressions, especially what
things are good already or worth more efforts.

Such detailed issues are best discussed simply using tickets and we have
plenty of them, for example:

- dropping buildings from z13

https://github.com/gravitystorm/openstreetmap-carto/pull/3467

- street workout icon design

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


-- 

"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] OpenStreetMap Carto release v4.17.0

[Daniel Koć]

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

[OSM-talk] OpenStreetMap Carto release v4.17.0

[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

-- 
"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] Missing country labels on default OSM.org layer

[Daniel Koć]

W dniu 20.11.2018 o 01:12, Pierre Béland pisze:
> This map I created let's dirty individual tiles when we click an area
> with the left mouse button.
> https://pierzen.dev.openstreetmap.org/osm-pixels/#4/65.333176/-93.885778


Did you mean _right_ mouse button? Well, I get only:

"erreur > "

with every action, even on z19.


-- 
"Excuse me, I have some growing up to do" [P. Gabriel]

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Missing country labels on default OSM.org layer

[Daniel Koć]

Hi,

Does anyone know what happened to the labels of USA and Canada on
standard OSM.org map? I hope we will release new OSM Carto version this
Friday and soon the low zoom levels (z0-z12) could be re-rendered, but
I'd like to be sure if something was not broken till then.

Some time ago I have proposed to render fresh low zoom tiles every
weekend (instead of 2 weeks), so such problems could be found and
repaired faster, but there's still no response from OSMF admins:

https://github.com/openstreetmap/chef/issues/184


-- 
"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] Plus code grid service

[Daniel Koć]

W dniu 19.11.2018 o 17:20, Mateusz Konieczny pisze:
> It is still not clear to me why new way of writing latitude and
> longitude is supposed to be interesting.


One of the reasons might be that it's about areas (covering some
interesting places), not points.


-- 
"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] OpenStreetMap Carto release v4.16.0

[Daniel Koć]

W dniu 20.10.2018 o 11:03, Stephan Knauss pisze:
> Bitmap based pre-rendered maps are always a trade-off.
>
> If you are looking for a more "google-like" dynamic map, then check
> out the vector tiles based maps which support search for amenities and
> can dynamically display features.

It doesn't have to be proper vector map. Dynamic overlay works against
simple bitmap background (including OSM Carto by default):

http://openpoimap.org

-- 
"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] OpenStreetMap Carto release v4.16.0

[Daniel Koć]

W dniu 20.10.2018 o 10:17, Maarten Deen pisze:
> With that argument you can delete all icons because "well mapped
> cities are cluttered". 


This is a straw man argument. No icons has been removed and it was not
even proposed, it's just about moving initial zoom levels and it's
enough. "Small" is not "invisible".


> Maybe there needs to be done something about that, instead of not
> showing information everywhere.


Nothing proposed in a month long debate was more objective and
universal. But maybe your proposition would be better - who knows, you
can try.

It would help to resolve urban/outdoor issue, but we currently don't
know how to detect when we could render things earlier without
cluttering the space.


> There is not even a hint that there is something now. Shops already
> get mapped as dots first, now atms are just invisible except at the
> highest zoom.


Of course there is no hint, since objects of this size just don't belong
here. The same is true for benches for example.


> Sorry, but IMHO this is a bad change.

Time will tell. However it took me many months to understand how we
could deal with non obvious problems and size rule seems to be the best
tool to avoid "importance wars".


-- 
"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] OpenStreetMap Carto release v4.16.0

[Daniel Koć]

W dniu 19.10.2018 o 07:39, Maarten Deen pisze:

> Does this mean that amenity=atm only gets rendered in zoom 19 and
> higher? If so, why? It is now rendered from 17 onward, shops get
> rendered from 18 onward.
> It seems to me that atms are at least as important as shops.


Yes, you get it right. I based this solution on size principle, because
this is the only universal rule I know that helps managing the mess
which is best visible on z17 in big, well mapped cities. Here are two
real life illustrations of the problem with small amenities I gave
during long and hot discussion:


https://github.com/gravitystorm/openstreetmap-carto/pull/3372#issuecomment-423373856
https://github.com/gravitystorm/openstreetmap-carto/pull/3372#issuecomment-426308795


( BTW: I've made a mistake in the subject, so I fix it now - it's
v4.16.0, not v4.15.0 )


-- 
"Excuse me, I have some growing up to do" [P. Gabriel]



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] OpenStreetMap Carto release v4.15.0

[Daniel Koć]

Dear all,

Today, v4.16.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
- Changing societal amenities color to less intensive
- Adding rendering for natural=strait
- Adding rendering for leisure=track on lines
- Adding icon for amenity=vehicle_inspection
- Adding icon for leisure=sports_centre + sport=swimming and
leisure=swimming_area
- Adding icon for tourism=gallery
- Changing color for aeroway=apron in aerodromes
- Moving amenity=post_box to z19+
- Moving amenity=atm to z19+
- Replacing icon for information=tactile_model
- Ordering amenity_lines by layer
- Small documentation and code fixes

Thanks to all the contributors for this release including dryo, a new
contributor|.|

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.15.0...v4.16.0

As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] OpenStreetMap Carto release v4.15.0

[Daniel Koć]

Dear all,

Today, v4.15.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
- Changing gastronomy objects color to orange (affects restaurant,
fast_food, ice_cream, food_court, bar, cafe, nightclub, pub and biergarten)
- Changing farmland and societal amenities (like school, hospital etc.)
colors to fit better into the overall color systematic
- Adding rendering for man_made=wastewater_plant and man_made=water_works
- Adding icon for man_made=storage_tank and man_made=silo
- Adding icon for amenity=bicycle_repair_station
- Adding icon for leisure=amusement_arcade
- Adding icon for shop=bookmaker
- Adding icon for shop=trade
- Adding rendering for attraction=water_slide
- Rendering most of the road links thinner (affects trunk_link,
primary_link, secondary_link)
- Moving manors to z16+
- Fixing missing country labels on z4 (affects Canada, Russia and Greenland)
- Small code and icon fixes

Thanks to all the contributors for this release.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.14.0...v4.15.0

As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-us] Proposition for changing the common name tag

[Daniel Koć]

W dniu 17.08.2018 o 03:50, OSM Volunteer stevea pisze:
> I agree with Kevin (and others) that adding "it is never incorrect to add it" 
> (can't hurt), usually helps and distinguishes Mexican states from the fifty 
> north of the Rio Grande (in some places). 

Brian Housel on the Slack US channel has noticed that "it will match
other every other map: Bing, Google, Apple, Mapbox, etc." This not
something I thought about myself, because I don't use these maps, but it
makes sense for me as strong proof that it's really THE common name of
this country for all the practical purposes.

I also think that it really can hurt to not follow tag definitions (and
intentions). That's why we have multiple "name*" tags family. People can
choose which version they prefer to use for their purposes and default
map style is just one possible use. If you want to have
official/political map, you can use official_name, with "United States
of America", to be perfectly sure and don't upset anyone. If you want
country names to not clutter the space or you want to show some other
data more prominently, you can use short_name, with just "USA". But when
you want just common names, you could use "name" tag containing "United
States". Using official name instead of common name is not the proper
solution in my view, rather kind of a hack.

Overall response for this proposition in last 5 days is favorable, but I
want to wait bit more to not act in hurry and give people a chance to
express any objections they might have.

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]



___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk] OpenStreetMap Carto release v4.13.0

[Daniel Koć]

W dniu 17.08.2018 o 19:49, Dave F pisze:
> Thanks for letting us know. Wasted half an hour checking it wasn't
> just me & providing examples.
>
> How about not posting until it's been deployed in future?

Hi Dave,

Multiple times before the release has been deployed eventually,
typically in days or even hours. This was a special moment when there
were some unusual works with hardware and software infrastructure and I
was not even aware that it will take so long, that 3 following releases
(!) won't be deployed at OSMF servers. Moreover release message does not
promise if and when this might occur ("Once changes are deployed on the
openstreetmap.org it will take couple of days before all tiles show the
new rendering.").

As this is very rare problem and would make release even more
complicated process, I rather won't follow this suggestion, sorry. BTW:
v4.14.0 deployment on OSMF servers has already started, so this time
announcement follows it.

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] OpenStreetMap Carto release v4.14.0

[Daniel Koć]

Dear all,

Yesterday, v4.14.0 of the OpenStreetMap Carto stylesheet (the default
stylesheet on the OSM website) has been released and rolled out to the
openstreetmap.org servers. It might take a couple of days before all
tiles show the new rendering.

Changes include
- Added text-repeat-distance for waterways
- Added text-repeat-distance for railways
- Added icon for leisure=bowling_alley
- Added icon for leisure=outdoor_seating
- Added icon for leisure=bird_hide
- Added icon for shop=video
- Added icon for shop=paint
- Added icon for shop=massage
- Increased casing width of tertiary road on z12
- Standard text halo for fitness_centre and fitness_station
- Updated Docker images definitions
- Small documentation updates

Thanks to all the contributors for this release.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.13.0...v4.14.0

As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-us] Proposition for changing the common name tag

[Daniel Koć]

W dniu 16.08.2018 o 19:33, Jack Burke pisze:
> Yes, when people say "United States" they typically mean America and
> not Mexico, but the USA is just as often referred to as "America" as
> it is "United States," which is another reason not to proceed with the
> change.

Hi, Jack!

I think that key word here is "common" - for me "typically mean America
and not Mexico" is a clear example of common use.

English is a foreign language for me, but I have also never heard about
"United States" in the meaning Mexico ("United Mexican States"), which
makes this case stronger for me.

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]



___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Proposition for changing the common name tag

[Daniel Koć]

W dniu 16.08.2018 o 19:43, Volker Schmidt pisze:

> Looks somewhat strange to me in view of the preamble of the US
> Constitution:
> " We the People of the United States, in Order to form a more perfect
> Union, establish Justice, insure domestic Tranquility, provide for the
> common defence, promote the general Welfare, and secure the Blessings
> of Liberty to ourselves and our Posterity, do ordain and establish
> this Constitution for the United States of America. "

Could you tell in your words what is strange for you, so we could
discuss things in more specific way?

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Proposition for changing the common name tag

[Daniel Koć]

Hi,

I wanted to let you know about proposed change in tagging the name of
USA and I seek for the feedback about it - see the proposition here:

https://forum.openstreetmap.org/viewtopic.php?id=63384





-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Daniel Koć]

W dniu 13.08.2018 o 19:23, Frederik Ramm pisze:

> Which code would you then add to a building? 

I guess I was not clear enough.

I meant only the case when there is proper sign on the building, I would
tag it as an address then. Then and only then. It's perfectly verifiable
and I don't have to decide anything.

For the buildings without a plate with OLC number I would not try to tag
it, exactly because it's not clear which number should it be.

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Is it technically and legally possible to add the Open Location Code to the OSM search?

[Daniel Koć]

W dniu 13.08.2018 o 18:37, Jo pisze:

> I also don't see a reason to add the OLC codes in tags in the
> database, even if marked on a building.

Since buildings are not guaranteed to fit into OLC rectangles and they
not 1:1 compatible, this usage makes sense for me.

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] 2 Great Lakes missing

[Daniel Koć]

Hi,

Is anybody aware what happened to Lake Superior and Lake Huron?

https://www.openstreetmap.org/relation/4039486

https://www.openstreetmap.org/relation/1205151


They were changed 20 and 3 days ago, respectively, and they stopped
being rendered both on default and on humanitarian map.


-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Render the names of the seas

[Daniel Koć]

W dniu 31.07.2018 o 13:31, Sérgio V. pisze:
>
> Hi, I realized that none of the usual OSM tile providers renders the
> names of the seas.
>
> I was tryingh to find it out in the map, because I allways mistake
> e.g. Caspian for Black Sea and vice-versa.
>
> Also oceans has dozens of seas.
>
> Why the names of the seas are not rendered? Would it be nice to have
> them rendered?

Hi,

This is probably an OSM Carto question. We have a special ticket for
this, please see the discussion there:

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

In  a nutshell: one problem is with nodes vs areas, the second one is
what language should be used to display them.

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] the new icon for the Tag:amenity=bureau_de_change

[Daniel Koć]

W dniu 25.07.2018 o 16:39, Colin Smale pisze:
> The Red Crystal symbol is protected by the ICRC. We can't use it, nor
> can we use the Red Cross or Red Crescent. There have been numerous
> legal cases which came down to the fact that these symbols are
> protected by international law. Even historical representations
> (vintage ambulances, hospitals etc) have an issue with this.

Well, what about red cross symbol then - isn't it also protected by ICRC?...

We had similar problem with shop=sports icon:

https://github.com/gravitystorm/openstreetmap-carto/issues/1530#issuecomment-99266644

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] the new icon for the Tag:amenity=bureau_de_change

[Daniel Koć]

W dniu 25.07.2018 o 15:34, oleksiy.muzal...@bluewin.ch pisze:

> There are 180 currencies recognized as legal tender in the world [1].
> I have nothing against USD and EUR, but why not to use a
> straightforward comprehensible generic icon, which covers all existing
> and future circulating currencies?

Too generic symbols are just not clear. Some examples as a symbol ("pars
pro toto") can be better instead and is used in multiple cases (look for
example at fast food or playground icons).

We have the same problem with hospital symbol. There's even an official
generic symbol that we could use, called "red crystal" (see
https://en.wikipedia.org/wiki/International_Red_Cross_and_Red_Crescent_Movement#The_Red_Crystal
) and I like it very much, but we still use red cross, because I think
nobody would recognize it.

I invite you to discuss this issue here:

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

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] OpenStreetMap Carto release v4.13.0

[Daniel Koć]

Dear all,

Today, v4.13.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:
- Increased shield distances on roads
- Added icon for shop=ticket
- Added icon for shop=houseware
- Added icon for shop=charity
- Added icon for shop=second_hand
- Added icon for shop=interior_decoration
- Added icon for amenity=bureau_de_change
- Added icon for amenity=casino
- Added icon for amenity=boat_rental
- Updated shop=department_store icon
- Small documentation and code fixes

Thanks to all the contributors for this release.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.12.0...v4.13.0

As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] API a lot slower?

[Daniel Koć]

W dniu 18.07.2018 o 14:40, Frederik Ramm pisze:

> Yes, the situation would be more relaxed if work were distributed on
> more shoulders but at this precise point in time I'd like our operations
> group to focus on getting the move done with minimum fuss, and not on
> recruiting new people!

First of all - I appreciate the work behind the hardware and software
support in OSMF. That is a huge bonus for me that in general I can focus
on developing default style without special care for the infrastructure
it will run on. Kudos for you all!

I also absolutely don't mean this precise moment. Being system
administrator myself, I can imagine how stressful and complicated that
could be. I just thought that there could be some message after the
solution has been selected and before the move has started. I try to
warn my users beforehand when doing anything that could directly affect
their work or if there's some risk involved. At least that's a Best
Practice TM. :-)

What I wanted to express was just a friendly moniker that OWG/EWG work
is still not visible from my perspective (even if I'm an active member
of OSM community) and that it could help to gain some people this way.
Especially as this aim was explicitly stated by technical team
(precisely I mean
https://blog.gravitystorm.co.uk/2016/07/28/getting-involved-in-owg/ -
BTW the same person that has successfully started and supported OSM
Carto team building!).

It's always hard to set the right priorities how much would one spend on
communicating and finding new people versus doing actual work, but my
experience is that it pays off to risk some evangelizing - now we have a
team of active people in OSM Carto again, but it required putting some
effort into making the style more available without clear outcome what
exactly might work. And we still keep trying - see this fresh announcement:

https://www.openstreetmap.org/user/Tomasz_W/diary/44420

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] API a lot slower?

[Daniel Koć]

W dniu 17.07.2018 o 14:55, Grant Slater pisze:

> Yes. We are moving some core servers to an Equinix data centre in
> Amsterdam, NL. 

Thanks for the message! However given how big this change is and that it
directly affects comfort of using OSM services, I would be glad to hear
much more details what are the plans and why there?

As I understand, OSMF technical department (I mean Operations Working
Group and Engineering Working Group) wants to engage more people
(https://blog.openstreetmap.org/category/organisation/osmf-working-groups/)
and giving some general informations in public is a basic tool to
encourage them.

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] API a lot slower?

[Daniel Koć]

W dniu 17.07.2018 o 12:22, Grant Slater pisze:
> Our primary hardware is moving to a new data centre next week, and
> will take some time to get up and running.

What data center do you mean? Is it the one which OSMF was looking for
at the beginning of the year?

https://blog.openstreetmap.org/2018/02/19/osmf-request-for-proposals-data-centre-2018/

Could you give some more details about it?

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] About OSM social implications and what can/should be displayed on the map (or not)

[Daniel Koć]

W dniu 29.06.2018 o 17:27, Carlos Cámara pisze:

> This is to say that openstreetmap-carto is OSM's business card, which
> should serve as an entry point to the project to people from many
> conditions and hence, we have a responsibility in deciding what do we
> display and how we do it

Of course. There's a nice poem of polish Noblist about the matter:

"Even when you take to the woods,
you`re taking political steps
on political grounds."

https://poezja.org/wz/Szymborska_Wis%C5%82awa/1980/[in_english]_Children_of_Our_Age

But it works both ways - not taking part or not doing something is also
one's responsibility:

"Whatever you say reverberates,
whatever you don`t say speaks for itself.
So either way you`re talking politics."

> (I'm sure we are all more or less aware of that and there are great
> efforts and success in making it a great default renderer -I honestly
> love how fast it has improved in recent time).

Nice to hear that, thanks! Not as fast as I'd like and is possible, but
it needs more active people in my opinion - especially coders at the moment.

> In order to overcome those matters (and if I am not wrong), so far the
> position on this regards is to render everything on
> openstreetmap-carto provided the following conditions: A) there is a
> significant number of uses (don't know how much is "significant"), B)
> someone creates an issue requesting for it, C) someone designs an icon
> or a representation for it, D) someone implements it by creating a
> Pull request that is merged into openstreetmap-carto project.

This is more or less accurate, however B is usually the first step and
C+D is sometimes where it starts. A is usually taken into account
together with documentation, how the tag is used, if there are some
competing schemes and how many people have used that - all of which can
be a source of debate. Usually tags starting with 2000-5000 uses are
pretty much significant, if no other factors are undermining that.

>  Or in other words, it is like European white heterosexual males were
> doing a kind of digital colonization of the world by imposing their
> rules simply because other groups are not participating in the
> decision-making process and hence their needs/opinions have not been
> taken into account.

I would be happy to see more people engaged in decision making in OSM
Carto, unfortunately it seems that only few people want to participate
to some degree. And that is also political will to not engage or not
help, which is powerful tool shaping the reality - don't forget about
it. Even if we try to take it into account, how could we be sure that we
represent them right?

We were asking about writing systems and the response was minimal. We
have a Code of Conduct. We made project overview, tutorials and easier
to use installation system. Diversity is one of our goals. If you know
what more is needed to attract them, please let us know.

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OpenStreetMap Carto design

[Daniel Koć]

W dniu 29.06.2018 o 11:06, Christoph Hormann pisze:

> I did not make any assumptions on avant-garde being a positive thing
> here.  In fact for a long time i have clearly said that i think that 
> OSM map design should become more pluralistic.  

It is now and it does not go away, so I still see no crossroad - just
more or less active.

> But historically 
> OSM-Carto has been and has meant to be avant-garde, in particular also 
> to justify being rendered on OSMF infrastructure.

It's very interesting, could you tell more about it? I'm not aware of
such comments and I'm not sure what "avant-garde" meant in this context.

I suspect it could be map richness, which is rather simple, but might be
seen as avant-garde. Also the act of collective design in itself might
be seen as ground breaking. But I wouldn't call it like that.

> You are making the wrong assumption here that code complexity and 
> cartographic sophistication always need to go together.  But they 
> don't.  There are plenty of examples of cartographic sophistication 
> being implemented without additional code complexity as well as code 
> complexity being added which was cartographically a step back.  

You're right, I used simplification. We deployed some simple code for
borders simplification for example and I was happy with that. Here I
talk only about avant-garde which currently requires workarounds.

> You are 
> also making the wrong implicit assumption that code complexity is the 
> only major factor that negatively affects developers' ability to 
> implement changes.

What are other factors then?

> about this.  And the unpaved roads rendering is not the problem here, 
> the problem is the complexity of roads rendering in general.

In my opinion there are two problems which add up - current road
complexity and surface code being Mapnik workaround too.

> Right now OSM-Carto is in the position of a quasi-monopoly in what it 
> does.  A potential competitor would need to mobilize a tile serving 
> infrastructure at least roughly on the same level as that of the OSMF 
> to seriously challenge it.  And this is quite a big hurdle.  This 
> creates a pretty stable comfort zone where OSM-Carto can rest idly even 
> if the world of digital cartography is progressing around it.

What do you define as the "serious competitor"? How do you measure it,
because there are a lot of styles using OSM data - including Wikimedia
maps style. Are they serious for you?

For me it's not the main problem, rather internal complexity which is
hard to avoid. No matter if the competitor exists or not, we're bound by
the tools and environment we're using, for example:

- https://github.com/gravitystorm/openstreetmap-carto/issues/2452 -
problem with lack of variables in YAML and/or CartoCSS parsing big lists
in SQL queries

- https://github.com/mapnik/mapnik/issues/3763 - lack of em measure in
Mapnik

- https://github.com/openstreetmap/chef/issues/155 - smarter label
placement has been implemented in mainstream Mapnik after I talked with
developers, but it's still not deployed on OSMF servers

...and so on.

The competitor would have to reimplement all of it or find better
toolchain, but OSM Carto could also use them if available, so it's still
the same problem.

But for rich map I see no such ready tools. Do you know any of them?

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OpenStreetMap Carto design

[Daniel Koć]

W dniu 29.06.2018 o 12:57, James pisze:
> But they say CartoCSS is dead, what is the intended replacement(if
> it's dead it's because there's a newer better thing?)? just a data
> structure that contains data/styling?

Being "dead" means it's no longer in development, but it's still
perfectly usable. 

It could be another "translator" from CartoCSS language into Mapnik XML
configuration, but it's not ready to be replacement at the moment, see here:

https://github.com/omniscale/magnacarto/issues/7#issuecomment-399771053

If you can help with development of any of them, that would be helpful.
Otherwise we're just limited with what we have, which means CartoCSS 1.0.0.

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OpenStreetMap Carto design

[Daniel Koć]

W dniu 29.06.2018 o 13:02, Christoph Hormann pisze:

> But the surface rendering from Lucas is something you could fairly well 
> re-integrate into a reworked road rendering framework afterwards - and 
> this is probably also the way i would approach it.

> How to implement something like that in an actual renderer is of course 
> not a trivial task.

That is core of the problem for me - not the approach, but deciding in
non-trivial cases, which is a lot of cases anyway...

My first choice would be to make road code cleanup - but that was just
started, then Paul stopped the work permanently:

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

With rendering surface - there was another implementation idea and code
attempt, but that has stopped too:

https://github.com/gravitystorm/openstreetmap-carto/pull/3083

And the ultimate choice would be to first implement Mapnik features for
what the Lucas wants, so his code would be cleaner.

Currently we're back to the ground zero - Lucas code has been reverted
and we can check the options again. But please, let be realistic,
because I can give you much more "proper" ideas, but I don't, because
they would not be useful.

And it's not only the surface rendering issue, but it's a great example
that talking is cheap and at the end of the day it matters more what can
and will be done.

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] WMF: "Interactive maps, now in your language"

[Daniel Koć]

W dniu 29.06.2018 o 14:03, Christoph Hormann pisze:
> * adding non-verifiable name translations (verifiability being 
> understood according to OSM principles, not those of Wikipedia) to OSM 

With translations "on the ground rule" is not working in most of the cases.

There are different sources, for example common name use in papers and
(for example in Poland) special naming commission (see
http://ksng.gugik.gov.pl/english/index.php ), which decisions are being
published as official law, but that is exactly Wikipedia way and I don't
see anything better here.

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OpenStreetMap Carto design

[Daniel Koć]

W dniu 29.06.2018 o 11:39, Frederik Ramm pisze:
> Hi,
>
>without going into the finer details, I'd like to offer an outsider's
> view of OSM Carto development.

Thanks, Frederik! I lack such insights (we know our ideas inside the
team quite well), so I appreciate your comments a lot.

I would be happy to hear more voices of the OSM Carto users (not only
developers) community.

> But after a
> while this small team has started milking the toolchain for all it's
> got, and meanwhile the SQL queries are so complex that they threaten to
> nullify any effort that has gone into making the style accessible to new
> participants (or people who want to customise it).

I believe this is mainly due to performance reasons which I mentioned. I
would be happy to transform them into styling decisions (MSS files), but
most probably that would hurt the hardware resources OSMF has. So this
is what I take as a hard limit that can't be fixed.

For me this is part of a deal to stay being default style - there is
default deployment one has to consider.

> So the ease of participating or customising has more or less already
> gone down the drain; what's still good about OSM Carto is that at least
> you can easily install it as-is on your own infrastructure (I regularly
> do that for business clients), but I fear it is only a matter of time
> until this aspect of usability, too, will be abandoned, and you will
> have to run massive pre-computation jobs in order to even get your map
> off the ground...

I understand that is what you're afraid of, but I don't expect any of
that. I like the simplicity and we're cautious even with external
dependencies on pre-computed data. IIRC, there was no discussion about
adding any new pre-requisites.

> Personally speaking, the OSM Carto map has been good enough for me and
> all my use cases for years now. If anything, I found the inflation of
> icons and special cases a bit irritating. I would love it if OSM Carto
> could be split into a "bread and butter" style that is easy to work
> with, easy on the eye and easy to render, and a "cartography
> navel-gazing" add-on where we show off how we can render different track
> patterns depending on the pebble size. We could then offer both on
> openstreetmap.org (where the bread-and-butter style would be the default).

Personally lack of shop icons was the deciding factor that pulled me
into developing OSM Carto...

It's much easier to create small utility script that removes unwanted
icons or turn them into simple dots than to add new icon (as you have
noticed it might take months or even years). Maybe deployment community
needs such customizing tools? As of now we have localization tool from
German fork, but maybe "modders" could make more such tools. I would be
all for creating such ecosystem. Feel free to contact me for details,
I'm ready to help to bootstrap it.

I also like the idea of simple and extended version, but I see two
problems with that:

1. Where to draw the line and who would decide what is "standard" and
what is "extra"?

2. It's again the hardware problem that is haunting us. If OSMF admins
would be ready, I could have multiple OSM Carto versions already, for
example with different languages. Of course anybody else could support
OSMF or run their own environment, but the hardware requirements are
quite heavy, and you already know it well:

https://help.openstreetmap.org/questions/64405/tile-server-hardware-requirements

What are your propositions regarding that?

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] OpenStreetMap Carto design

[Daniel Koć]

(Taken from dev list, because this is wider problem.)

W dniu 23.06.2018 o 10:55, Christoph Hormann pisze:

> All in all this is a good example for OSM-Carto being at a crossroads 
> (and having been for quite some time) between staying avant-garde and 
> pushing the boundaries of cartographic design and technology or being 
> satisfied with shuffling the options offered by the cartographic 
> mainstream within the technological framework used - and which, due to 
> Mapnik and CartoCSS being essentially unmaintained, becomes more narrow 
> and limiting every year.

I don't see a crossroad here: being avant-garde in cartographical sense
might sound cool, proud and tempting, but that comes at the high price -
maintainability and team work problems.

This style codebase is large and that might sound like causing a problem
with maintenance, but adding more features is far less challenging than
something as sophisticated as for example "new" road code - and nobody
seems to be even noticing how complicated it became.

Now, I'm happy with the road system look in osm-carto and it was
probably worth the hassle, because it's essential element of the generic
map. I also think that support for paved/unpaved roads is important,
because many people seem to care about this feature for a long time (I
hope Lucas can fix the performance problem, so it could be merged
again). But probably some more naive rendering with simpler code would
be better - it just hasn't been done.

So from time to time some fine tuning might be good, but it usually
means stretching the code in dangerous ways. It's already hard because
of a performance factor - we push some design choices into scary giant
SQL queries, but that is needed because of the growing database size and
not so fast growing hardware capabilities.

Your own fork looks to me like a typical prototype: expressing some
interesting ideas, but not really ready for wider usage. Bolder style
seems to be another prototype, with more technical than cartographical
ideas, and more radical - going from zero with a new software stack.

It's good to have some prototypes around, but I'm pretty sure that
standard map should stay mainstream. This way or another we rely on
other software, especially Mapnik. The generic style is not a place to
try cartographic innovations if it makes the code even more complicated.
Expressing ideas in a more or less standard way is very important, so it
won't end up as too hard to maintain by a group of people, not just one
clever designer.

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] OpenStreetMap Carto release v4.12.0

[Daniel Koć]

Dear all,

Today, v4.12.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:

Major changes
- Dropped subpixel accuracy for areas, which includes tuning some
database indexes. When deployed, it might speed up reading data.

Changes
- Added rendering “surface” tag on roads with a pattern
- More vertical objects rendering and tuning (man_made=tower types,
man_made=chimney, man_made=communications_tower)
- tourism=information types rendering and tuning
(information=audioguide, board, guidepost, map, office, tactile_map,
tactile_model and terminal)
- Added rendering for place=quarter
- Added rendering of historic=city_gate
- Added rendering of lock_name
- Ditch and drain name labels are rendered with some offset
- Pixel aligned ford icon
- Made amenity=shelter icon brown
- Finer man_made=pier width rendering
- Rendering living street tunnels different from residential
- Added rendering of overground power=cable like power=line
- Small documentation and code fixes

Thanks to all the contributors for this release including Adamant36 and
M1dgard, new contributors. I also like to thank nebulon42 who left our
team due to a change of his priorities for all the work on this style
and the tools we're using!

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.11.0...v4.12.0

As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] OpenStreetMap Carto release v4.11.0

[Daniel Koć]

Dear all,

Today, v4.11.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
- Fixed office/amenity conflict
- Brightened built-up areas on z12
- Refurbished natural=spring icon
- Added rendering for amenity=police and amenity=fire_station areas
- Added rendering of amenity=nursing_home
- Added rendering of amenity=childcare
- Added rendering of amenity=driving_school
- Added area rendering for amenity=bus_station
- Added area rendering of amenity=taxi
- Made highway=traffic_signals icon less obtrusive
- Moved barriers to higher zoom level
- Hiding railway=platform with location=underground, tunnels and covered=yes
- Small documentation and code fixes


Thanks to all the contributors for this release.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.10.0...v4.11.0

As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Local language help

[Daniel Koć]

W dniu 08.05.2018 o 21:31, Yuri Astrakhan pisze:

> This query shows a list of regions that have the new default_language
> tag (you can multisort column with shift or control clicking the
> headers).  http://tinyurl.com/yd6bx6s3

What about places like Morocco? Shouldn't it be rather similar to
Belgium - "fr ber ar" (because the name is "Maroc ⵍⵎⵖⵔⵉⴱ المغرب") than
just "ar"?

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM and new Wikipedia map features

[Daniel Koć]

W dniu 04.05.2018 o 02:30, Yuri Astrakhan pisze:
> Daniel, the only real difference between serving every available
> language and serving just one is cache fragmentation, and that's may
> be different in your case.

Sure, but you're talking about just one link of the chain. The WMF
vector tiles are produced from a database, rasterized somewhere down the
line, then probably written on the disk, served, cached etc, so it's not
that simple.

That's why I ask about the bottom line in this specific case. There are
many factors which will be different (like how complex the style is, for
example), but it's good to estimate the order of magnitude at least. But
all the details are also interesting to me.

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM and new Wikipedia map features

[Daniel Koć]

W dniu 04.05.2018 o 01:17, Joe Matazzoni pisze:

> b) how many server resources do you need for rendering  languages
> that you want to support (not the software stack used)?
>
> ?? Are you asking about OSM resources or WMF resources?

I mean WMF resources.

I'm asking because we want to have localized maps in OSM too and
rendering just one (default) raster style eats most of the resources of
4 servers. This would not work for (let's say) 300 language versions, of
course.

We refresh default rendering in minutes usually, but even if we use more
relaxed times for localized maps, it's still too much - with 1 language
per day we would refresh them all once a year...

We think about vector style migration lately, so it might help here, but
I don't think this will work like 100x times faster.

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM and new Wikipedia map features

[Daniel Koć]

W dniu 04.05.2018 o 00:33, Joe Matazzoni pisze:

> Here is the list of languages Wikimedia
> supports. https://en.wikipedia.org/wiki/Special:SiteMatrix
> 
>  .
> As to the toolchain, if you ask that question on the project page,
> some of our engineers will be able to respond.  Be sure to explain why
> you’re asking, so we can answer you fully.

It's not exactly what interests me:

a) do you want to support all these languages (not how many of them are
there)?

b) how many server resources do you need for rendering  languages
that you want to support (not the software stack used)?

Do you know it or should I ask the engineers anyway?

> That is a very interesting edge case we hadn’t thought of.  We’ll have
> to look into that one; our lead engineer just wrote a ticket to
> investigate: https://phabricator.wikimedia.org/T193815
> .
>  I know about Serbian. What other languages do this?

Belorusian has two writing systems (see http://openstreetmap.by for 4
languages demo).

Chineese has few different writing systems.

Buginese can use Lontara or Latin script.


There might be more of such cases.

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM and new Wikipedia map features

[Daniel Koć]

W dniu 03.05.2018 o 23:20, Yuri Astrakhan pisze:

> I have posted in another threads about this, proposing
> "default_language" tag to be added to the admin (or smaller) regions
> to solve this. 

I like this proposition. I was talking about "official_language", but
they might be added where they are known and defined, yet most of the
time "default_language" would be the best solution.

But we need to distinguish two different cases: hint for debugging
"name" tag (or any other, like "alt_name", for that matter) and real set
of default languages, for example:

name=België / Belgique / Belgien
name:default_language=nl / fr / de
default_language=de;fr;nl

You can analyze "name" (which might be specially crafted, for example to
be shorter) or just glue proper values like name:de, name:fr and name:nl
somehow, whatever suits your needs better.

We should also think of different scripts or conventions used with the
same language. Example:

name=Norge
name:default_language=nb

name:nb=Norge
name:nn=Noreg
default_language=nb;nn

Another example (I have to use some guess work):

name=中国
name:default_language=zh

name:zh=中国
name:zh-classical=中國
name:zh-hans=中国
name:zh-hant=中國
name:zh-min-nan=Tiong-hôa
name:zh-simplified=中国
name:zh-traditional=中國
name:zh-yue=中國
name:zh_pinyin=Zhōngguó
default_language=zh

(well, probably...)

> Copying the rules:
>
> * Use the largest possible admin region to set the "default_language"
> tag to a single language code.  "default_language" does not mean the
> official language of the region. It only specifies the language of the
> "name" tag.
> * A region may contain a sub-region with a different default_language.
> * If a region uses mixed languages in all of its name tags, eg. "[name
> in en] - [name in zh]", set default_language="en - zh".  Try to keep
> it to a somewhat parsable value to help data consumers.
> * In some rare cases, additional non-admin regions might be required
> for the default_language.  Try to avoid it if possible.

I would also add "default_language=none". It's not needed until you make
the cascading definitions (inheritance). When you don't know or it's
just hard to get right, it's good to "switch off" and fallback to what
we have now.

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM and new Wikipedia map features

[Daniel Koć]

W dniu 03.05.2018 o 22:49, Joe Matazzoni pisze:

> Please post your thoughts and ideas to the project talk page [4].
> Thanks for your help, and for providing the valuable service you do to
> Wikimedia contributors and readers around the world. 

I will try to put my thoughts there.

However I also have some questions for you:

1. The localized maps lack fallback rules (I'm speaking of Polish
language at least). I would ask for English as a fallback for maps in
Polish, but I don't know where should it be requested or configured? Is
this list the right place?:

https://github.com/kartotherian/babel/blob/master/lib/fallbacks.json

2. How many languages do you want to support in total and what hardware
resources are needed for that using your toolchain?

3. What about the same language using different scripts, do you plan to
support them all?

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Wikimedia Maps deployment

[Daniel Koć]

Hi,

Wikimedia are currently working hard on deploying maps based on OSM data
- some basic information and links are here:

https://forum.openstreetmap.org/viewtopic.php?id=62086

Now they started including them on the project Wikis:

https://www.mediawiki.org/wiki/Maps#Wikimedia_projects_that_have_Maps_enabled

What is important for us is that these maps can have defined language
and Wikimedians will try to add localized names for different places.
However they don't know how to do it properly, so it might end up with
massive low quality name imports from Wikidata.

It would be good to prepare step-by-step guide to help them to resolve
this issue:

https://phabricator.wikimedia.org/T193656

We have a page related to Wikipedia/Wikimedia on our wiki, where it
could be linked along with native Wikimedia Maps page:

https://wiki.openstreetmap.org/wiki/Wikipedia

https://www.mediawiki.org/wiki/Maps#How_to_guides_and_more_information

***

Apart from these problems, I'm very happy with reusing our data for such
an important open project.

It's also good that they were able to deploy multiple language versions
- we would hit this problem anyway, sooner or later, and I hope that
eventually we will be able to provide them too.


-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Name:* tags in the local language

[Daniel Koć]

W dniu 26.04.2018 o 15:36, Martin Koppenhoefer pisze:
>
> 2018-04-26 14:16 GMT+02:00 Daniel Koć <daniel@koć.pl
> <mailto:daniel@ko%C4%87.pl>>:
>
>
> Isn't it like this:
>
> Country Belgium - official_language=de;fr;nl
> Region Brussels-Capital - official_language=fr;nl
> City Eupen - official_language=de
>
> What would be wrong with this scheme?
>
>
>
> it is only about "official languages" and it would somehow imply we
> would not want names added through ground truth for cases where the
> language the name is in, would not be recognized as an official language.

Sure, that's why I suggested common_language=* (common_language=xx +
name:xx=* is just like saying "name=* is in xx").

Could you explain this problem using some examples?

> I also don't know what this would imply for areas without formal
> government / disputed areas. Whose "official" language would we tag?

That's interesting case. How do we tag the borders for such areas?

If countries/regions with known official_language=* are overlapping, the
language would be known for both and you have to choose one or show both
(the same as official_language=xx;yy).

Another solution would be to use some special values, like "none" or
"disputed" for this area (unfortunately "no" is a code for Norwegian
language).

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Name:* tags in the local language

[Daniel Koć]

W dniu 26.04.2018 o 14:32, Philip Barnes pisze:
> If a place in England should we assume its name is in English?
>
> Name:en=Llanymynech would be a very odd assumption. As would Hengoed
> or Rhydycroesau.
>
> This cannot be automatic, it needs mappers with local knowledge.

That's pretty sane /general/ assumption, but rules can have /specific/
corner cases, like these. Note that nobody has added name:en=Llanymynech
- it's only name=Llanymynech, see:

https://www.openstreetmap.org/node/29750244

In this case local knowledge is probably to *not add* name:en=*. The
data consumer has no "en" value to render (let's talk about rendering
for example), so she can fall back to just name=* value - or just skip
it, if she wants to show only English names (why not?).

What I propose is to have some general assumptions, but in specific
cases these can be overriden (like official_name=cy for example) or
ommited (if not applicable - for example we don't know the language or
we don't have time to add so specific data and name=* is enough).

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Name:* tags in the local language

[Daniel Koć]

W dniu 26.04.2018 o 14:49, Marc Gemis pisze:
> The name for the country in the name tag is " België / Belgique / Belgien" (*)
> The name for any street in Brussels is either " - "
> or " - " with the majority mapped with French in
> front.
>
> The names never use a semi-colon. Without looking at name:fr / name:nl
> tags you don't know which part of the name belongs to which language
> (I think).
> For Belgium there is no problem, as the names will only contain latin
> characters, but in other cases it might become difficult, not ?

1. In database we store values, not typographic conventions, that's why
semicolon to separate multiple values.

2. The data consumer can decide what type of separator she wants to use.
It's data presentation part, not data storage. One can decide to show "
België - Belgique - Belgien" for example or fall back to name and so on.
The same with streets: one may always render " - " or
"/" or whatever else (like one in bold and the second
one in italics).

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Name:* tags in the local language

[Daniel Koć]

W dniu 26.04.2018 o 13:53, Marc Gemis pisze:
> Do you now assume that names in region B outside city C have a
> namehr;nameit in the name tag?

Yes, unless stated otherwise for cities E, F and G.

To be clear: I assume only that if they name:hr=* and name:it=*, both
are official, but that doesn't mean both need to be tagged (one or more
name tag may be just missing).

> That's not how we have done it for Belgium or any street in Brussels.

Isn't it like this:

Country Belgium - official_language=de;fr;nl
Region Brussels-Capital - official_language=fr;nl
City Eupen - official_language=de

What would be wrong with this scheme?

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Name:* tags in the local language

[Daniel Koć]

W dniu 26.04.2018 o 11:51, Mateusz Konieczny pisze:
> It is not handling
> - regions with more than one widespread language
> - features that have name tag in an atypical language

In my opinion there's no single solution for atypical cases, yet it's
sane to start with defaults. It can be used on many levels and region
can have more than one language defined, just like Janjko has shown:

Country A - official_language=hr
Region B - official_language=hr;it
City C - official_language=it

When a data consumer tries to find what is the official language for
street D, she finds that city C uses "it", so it's enough to know that
the street should be also in "it". Speaking of regions this is the
proper handling in my opinion - in region B you can for example use both
languages or choose the one you prefer, it's up to you.

But we don't have to stop with level 2, 4, or 6. If - for some reason -
part of the city is different and we have no way to show the borders of
the area, one can add official_language=* for the streets or objects in
this particular area. Of course instead of official_language we may use
default_language=* or common_language=* tag or something similar, the
same as the users have to choose common name for name=*.

This way we can always assume some language for the (administrative)
area, but if it's not true locally, we can be more specific, up to the
single objects.

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] OpenStreetMap Carto release v4.10.0

[Daniel Koć]

Dear all,

Today, v4.10.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
- Adding rendering for historic=castle and historic=manor
- Adding rendering office=* as dots + names
- Adding rendering for waterway=waterfall
- Adding place=square name rendering for nodes
- Adding rendering for big natural=bay
- Adding rendering for leisure=beach_resort
- Adding rendering for amenity=parking_space
- Adding rendering of aerialway=zip_line
- Adding rendering for shop=bed
- Adding rendering for shop=video_games
- Adding halo to roads on z6 and z7
- Extending intermittent waterbody rendering to landuse=basin
- Moving highway=mini_roundabout rendering to higher zoom level
- Dropping waterway=derelict_canal rendering
- Small documentation and code fixes

Thanks to all the contributors for this release, including d3d9,
doktorpixel14 and hikemaniac, new contributors.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.9.0...v4.10.0

As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Maps rendering forum

[Daniel Koć]

Hi,

I think we need a place to discuss maps rendering using OSM data, so I
created special subforum to talk about it:

https://forum.openstreetmap.org/viewforum.php?id=100


-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [OSM-dev] OpenStreetMap Carto release v4.9.0

[Daniel Koć]

W dniu 23.03.2018 o 15:43, Stefan Keller pisze:

> How can I help implementing rendering of castles (forts, ruins,
> manors, palaces)?
> https://github.com/gravitystorm/openstreetmap-carto/issues/744

Thanks! Well, I'm not sure - it's mostly about weighting the problems
and picking the proper solutions now, so any help with making decisions
will do.


With historic=ruins (of course it's not in the historic=castle tagging)
it's easier, I feel we're pretty close to find a proper icon:

https://github.com/gravitystorm/openstreetmap-carto/issues/331#issuecomment-372013931


However with the rest (castles, fortresses, palaces, manors, stately...)
all the icons are more or less ready, but we have a problem what to do
with having different valid and used in practice tagging schemes and the
discussion on the Tagging list still does not make it clear enough for me:

https://github.com/gravitystorm/openstreetmap-carto/pull/3099#issuecomment-374607590

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] OpenStreetMap Carto release v4.9.0

[Daniel Koć]

Dear all,

Today, v4.9.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

Major changes
- A bug where closed ways with natural=cliff or natural=tree_row were
not rendering has been fixed. This required fixing a transform bug. The
fix will apply to all objects when they are created in OSM, but there is
no migration for existing databases. Deployments will have to decide if
the effects are serious enough to require them to reload the database.

Changes
- Adding place=square name rendering
- Adding rendering for different types of towers and masts
- Making gardens to use grass color with plant nursery pattern
- Adding rendering for intermittent water bodies
- Give oceans outline and simplify shapefiles on z0-7
- Simplify (generalize) admin borders
- Move natural=grassland and landuse=meadow earlier
- Start rendering aerialway name
- Adding icons for amenity=bbq, amenity=shower, leisure=sauna and
advertising=column
- Adding special icons for shop=dairy, shop=medical_supply and shop=music
- Move amenity=toilets to higher zoom levels
- Fixing some SVG icons artifacts
- Make military=danger_area font dark pink and slanted
- Changing rendering for construction=steps to distinguish it from roads
- Changing label colour of private parking
- Small documentation and code fixes

Thanks to all the contributors for this release, including james2432,
Penegal and jragusa, new contributors.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.8.0...v4.9.0

As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Standard map style contributions

[Daniel Koć]

Hi,

Sorry for resurrecting the old post, but I've just made a list of the 
osm-carto issues which are missing the not too complicated coding part 
to be rendered - maybe somebody would like to try:


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


W dniu 28.12.2017 o 11:45, Daniel Koć pisze:

Hi,

We have a lot of tickets waiting for solving in osm-carto (almost 400) 
and I'm interested how could we do it effectively.


It's not realistic to expect that the core team would be able to catch 
up and that's why we took some care to help other people to 
contribute. Most important thing was preparing the Docker environment, 
which makes installing and testing a lot easier, but there are also 
some documents explaining the inner working of the project and even 
some very easy tasks to pick:


https://github.com/gravitystorm/openstreetmap-carto/labels/good%20first%20issue 



However after almost half a year we still don't have too many 
contributions from other people and I'm curious what are the main 
obstacles which prevent it and what else could we possibly change to 
make it easier? There's also more basic question: how many people are 
interested in contributing to osm-carto at all?





--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Donation from the Pineapple Fund

[Daniel Koć]

Hi,

You might remember news about big bitcoin donation from the Pineapple Fund:

https://blog.openstreetmap.org/2018/01/11/donation-from-pineapple-fund/

I wonder how OSMF plans to use it?

This is substantial amount of money, however I'm aware that it's just a 
one time shot and not a big change for the OSM in the long run - it's 
"only" about 2x more than yearly income:


"Our total income in 2016, without SOTM, was £124,000."

https://wiki.osmfoundation.org/wiki/Finances/Treasurer%27s_Report_for_the_December_2017_AGM


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] OpenStreetMap Carto release v4.8.0

[Daniel Koć]

Dear all,

Today, v4.8.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
- Made military area rendering less prominent
- Adding rendering for historic=wayside_shrine
- Adding rendering for historic=fort
- Adding rendering for amenity=public_bath
- Adding rendering for shop=chocolate
- Adding rendering for barrier=toll_booth (nodes)
- Adding rendering barrier=log
- Adding rendering for amenity=waste_disposal
- Moving tourism-boundary under barrier layer
- Docker: run osm2pgsql in slim mode
- Fix operator precedence for hstore queries
- Small documentation fixes

Thanks to all the contributors for this release, including jbelien, 
MKuranowski, andrzej-r and Zverik, new contributors.


For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.7.0...v4.8.0

As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues

--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] OpenStreetMap Carto release v4.7.1

[Daniel Koć]

|Dear all, Today, v4.7.1 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. This is a bugfix release, the only 
change is a code fixing this rendering problem: 
https://github.com/gravitystorm/openstreetmap-carto/issues/3043 Thanks 
to all the contributors for this release. For a full list of commits, 
see 
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.7.0...v4.7.1 
As always, we welcome any bug reports at 
https://github.com/gravitystorm/openstreetmap-carto/issues|


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] OpenStreetMap Carto release v4.7.0

[Daniel Koć]

Dear all,

Today, v4.7.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
- Adding icon for tourism=apartment
- Adding icon for leisure=firepit
- Yellow background for amenity=arts_centre
- Start rendering natural=heath earlier
- Start rendering entrances
- Changing tourism=picnic_site icon colour to green
- Move emergency=phone to higher zoom level
- Rendering seasonal waterways as intermittent
- Update Noto fonts to Phase III
- Fine-tuning of bridge labels
- Documentation changes and updates

Thanks to all the contributors for this release.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.6.0...v4.7.0

As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues

--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Brazil and Bolivia labels missing

[Daniel Koć]

Hi,

I've just found that Brazil and Bolivia labels are missing on the main 
page. They were visible not so long ago:


https://commons.wikimedia.org/wiki/File:OpenStreetMap_homepage_2017_en.png

so most probably this is a tagging problem, not an osm-carto problem.


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Mapzen is shutting down

[Daniel Koć]

W dniu 08.01.2018 o 00:22, Steve Coast pisze:

A few of us are working on this -

https://www.maphaven.com

Map services with the profits going to open mapping.


That sounds very intriguing for me, but the page is just vague at the 
moment. Could you provide us some more details?


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Standard map style contributions

[Daniel Koć]

W dniu 29.12.2017 o 03:41, Andy Townsend pisze:

Speaking entirely personally, the main issue is just selfishness/laziness.


I wouldn't name it "laziness" or "selfishness", just lack of motivation 
and I understand why - you have enough motivation to develop your own 
fork, so it seems to me that you have just different needs (but you 
still hint us how do you solve different problems, which is helping).


This is also a kind of problem which is hard to solve, because it's not 
clear to me what makes people do anything more than just opening a ticket.


In case it helps anyone who does want to contribute but doesn't quite 
know where to start I've added a diary entry 
https://www.openstreetmap.org/user/SomeoneElse/diary/43041 that 
explains what I needed to do to submit 
https://github.com/gravitystorm/openstreetmap-carto/pull/2966 .


Thanks a lot for sharing your experience! I have added this link to the 
OSM Carto Wiki page.


I'd also not assume that everyone is familar with CSS.  In addition, 
the somewhat arcane way that some of the selections for layers are 
done in project.mml is, shall we say, not always that easy to follow.


Of course, but it doesn't sound to me as a major obstacle. I'm not even 
a coder in any language, all I can do is looking for analogies (with 
both CSS and SQL parts), testing in Kosmtik and asking if I don't 
understand something.


There are many "low-hanging fruits", which don't need any special 
skills, just playing with a code and communicating. There is also a 
demand for icons for different things and we look for people who can 
just use Inkscape, which means no coding at all.


Another reason why I've not added more pull requests is that in some 
cases I don't think that they'd be accepted.


Another reason is I suspect the "jumping through hoops" needed to get 
something accepted. 



With the last two issues it's difficult to know what to suggest


Yes, it's hard to find a solution for such general issues. I still hope 
we could recognize some other problems, which are more "fixable".


Anyway, I hope the above helps (and please understand that it's not 
meant as a criticism either of the style or the maintainers - it's 
just trying to provide answers to the questions that were asked).


Thanks, Andy - that's exactly the kind of the input I expected: personal 
and detailed. I wait to hear more such real stories, even if they ended 
up with not even a single line of code.


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Standard map style contributions

[Daniel Koć]

W dniu 28.12.2017 o 14:34, James pisze:
Although the rest seems like CSS or a variation there of the project 
is big and they may not grasp everything. Proper documentation for me 
is a major factor, if the project doesnt have 
documentation(developement not user guides or at least well placed 
comments) it helps people get into it faster as they know what parts 
do what vs reading all of the project and guessing what parts do what.


I've written a general overview on Wiki lately to understand the basic 
parts of osm-carto:


https://wiki.openstreetmap.org/wiki/Standard_tile_layer

Detailed documentation is in the repo, especially in this file:

https://github.com/gravitystorm/openstreetmap-carto/blob/master/CONTRIBUTING.md

However I'm not able to guess what exactly is needed, since I'm involved 
in it for too long and because nobody is asking questions about how to 
start.


It also depends on how many people are interested at all and what is 
their background. For 1-2 persons it'll be easier for me to help 
personally case by case (which I'm willing to do), while for 10-20 it 
makes sense to develop more documentation or explain some examples in 
the diary.


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Standard map style contributions

[Daniel Koć]

W dniu 28.12.2017 o 14:04, James pisze:

not everyone knows lua scripting might be one of the major herdles


Is this what keeps you away from the code or there are some other 
obstacles? I'm most interested in hearing personal reasons, whatever 
they might be.


Fortunately lua scripting is not needed most of the time. For example I 
never had to touch it, though I make a lot of changes in osm-carto, so I 
would not worry about it.


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Standard map style contributions

[Daniel Koć]

Hi,

We have a lot of tickets waiting for solving in osm-carto (almost 400) 
and I'm interested how could we do it effectively.


It's not realistic to expect that the core team would be able to catch 
up and that's why we took some care to help other people to contribute. 
Most important thing was preparing the Docker environment, which makes 
installing and testing a lot easier, but there are also some documents 
explaining the inner working of the project and even some very easy 
tasks to pick:


https://github.com/gravitystorm/openstreetmap-carto/labels/good%20first%20issue

However after almost half a year we still don't have too many 
contributions from other people and I'm curious what are the main 
obstacles which prevent it and what else could we possibly change to 
make it easier? There's also more basic question: how many people are 
interested in contributing to osm-carto at all?



--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Maritime borders rules

[Daniel Koć]

About a month ago maritime border of Peru has been changed from commonly 
used Territorial Seas to Exclusive Economic Zone (EEZ):


http://www.openstreetmap.org/changeset/53890344

The problem has been reported, but it's still not clear if some global 
rules should be applied here:


https://help.openstreetmap.org/questions/57394/maritime-border-of-peru

--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OpenStreetMap Carto release v4.6.0

[Daniel Koć]

W dniu 17.12.2017 o 23:00, nwastra pisze:


“- Do not render small national parks and nature reserves”
At what zoom levels are they not rendered?
Surely these are still rendered when zoomed in close on the map and I would 
consider a higher priority of importance  that most other stuff that is 
rendered.


"Small" means "smaller than 3000 px on any given zoom level" (which was 
previously used only for rendeing labels) instead of 100 px limit:


https://github.com/gravitystorm/openstreetmap-carto/pull/2119/files

In other words - now we show their shape only if they are big enough to 
have labels on the zoom level you are using currently. They will be 
shown once you zoom in, so they're bigger than 3000 px. Of course labels 
can be not visible due to some other labels or icons placed on 
conflicting positions.


The rendering on OSMF servers is currently being updated.

--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM website stats on the end of the year

[Daniel Koć]

W dniu 13.12.2017 o 09:29, Tom Pfeifer pisze:

What measurements are these estimates based on?


AFAIK they collect the data through the browser toolbar:

https://www.alexa.com/toolbar

--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] OSM website stats on the end of the year

[Daniel Koć]

I've just visited Alexa free stats on OSM website and here are some 
interesting facts:


- Current Global Rank for OSM: 6988 (down 833)

- Most visitors come from USA, Germany, China, UK and France (in both 
USA and China rank number is lower than global average, but probably 
much more people live there, hence #1 and #3...)


- In the last year percent of visitors coming from the search engines 
increased from ~20% to ~30%


- Most of the people were visiting Google, Yandex and Wikipedia sites 
immediately before


- 4/5 most popular keywords of searching visitors are related to OSM 
(fun fact: "bing maps" is #2...)


- Comparing to average "Internet population" there are much more males 
and less females



[ https://www.alexa.com/siteinfo/openstreetmap.org ]


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Planned rendering changes of protected areas

[Daniel Koć]

W dniu 11.12.2017 o 14:43, Greg Troxel pisze:


The property that is denoted by leisure=nature_reserve is mostly
separate from the protected area information.  It means that humans are
able to hike in a land wich is in a natural state.


In the meantime I've made a reality check with Poland lately and now I 
think that local conventions could not be simply translated into 
protection class, so I agree that they are separate probably. For 
example most of national parks in Poland are IUCN class 2, but two of 
them are class 5. See my current report:


https://github.com/gravitystorm/openstreetmap-carto/issues/603#issuecomment-350587768

So now I would not advocate for deprecating "nature_reserve", as this is 
local specific type/name of protected areas. What I still think is 
wrong, is the key "leisure=". I think "boundary=protected_area + 
protected_area=nature_reserve" would be better (we already use such 
scheme for amenity=social_facility for example).



You're basically saying "I care about X, and you care about Y, and my
caring about X is more important, so you are wrong."


I care for proper naming and clear database scheme, not for any 
particular features. Leisure is just a popular activity related to many 
nature reserves, but not for all - think of strict reserves. But all of 
them are meant for nature protection, by design.



That's one person's opinion about some things.  The real world is
complicated and "protected" is very complicated.Certainly around me
there are "wildlife refuges" that allow deer hunting (to protect plants
and toher animals from deer!).


Yes, you are right that there are many views on how the protection is 
implemented. However "protection" is an umbrella term that binds all of 
the nature reserves (including "hunting allowed", "leisure allowed" or 
"voluntary protection"), but "leisure" does not include all of nature 
reserves.



What I don't understand is why you dislike leisure=nature_reserve so
much.  If you want to have boundary=protected_area control the rendering
if both are set, whatever.  But there seems to be some notion that
poeople using that tag causes you trouble, and that you have some basis
to demand that they stop.


Of course I have some trouble, otherwise I wouldn't notice. But that was 
just a trigger to see the real tagging problem, which is bigger than 
just rendering. As I understand you, what you think is "any tag you 
like" is the only policy that really counts, no matter if the scheme is 
precise, coherent and has at least basic classification.


For example I think that:

boundary = protected_area
+ protected_area = nature_reserve/national park/landscape reserve/...
+ protect_class = n

is better than:

leisure = nature_reserve
boundary = national park
boundary = protected_area + protect_class = n

The first one allows to add many properties in a reach and structured 
way, while the second:

- has no hierarchy
- implies "leisure" for every nature reserve
- does not allow to use boundary=national park + 
boundary=protected_area, because they share the same key


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Planned rendering changes of protected areas

[Daniel Koć]

W dniu 07.12.2017 o 17:04, Greg Troxel pisze:

I also object to deprecating leisure=nature_reserve.  The protected_area
scheme is too complicated for most people to deal with fully and
leisure=nature_reserve has proved itself to be useful.


This way or another it seems to me that leisure= key is wrong and using 
boundary=protected_area (or even just boundary=) is proper.


Leisure is just a common, but not the inherent property of nature 
reserve - the protection is:


"Usage of a leisure key, actually, might contradict a protection status 
in a lot of cases, where nature reserve doesn't allow any leisure 
activities. Ownership and enforcement are totally different things from 
protection level. For example, in Russian Federation, there are huge 
state-owned protected areas with limited access intended for hunting. 
They have strict protection enforcement and they usually are equal to 
class 4 or 6. Private hunting lands with similar access restriction, 
management level, and enforcement exist in other countries. Someone 
might argue that if hunting is allowed, it is not a protection, but 
that's just a personal idea of protection."


[ http://www.openstreetmap.org/user/kocio/diary/42861#comment40293 ]


Agreed.   To me, the real rendering issue si the lack of showing
protected area, and the tendency to show these features by an edge
marking rather than some kind of fill.


There are some tricks to make rendering better and I'm gonna try them, 
but lack of classification of nature reserves is a bigger problem than 
just rendering on osm-carto.


We also use a workaround for airports and it works, but using hacks at 
all means that there is a deeper problem.


With rivers we don't even have a hack and this is the same problem with 
lack of classification for very popular kind of objects.


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Tagging/rendering relations

[Daniel Koć]

W dniu 03.12.2017 o 19:31, Yves pisze:

Because the discussion can be heated by the fear of seeing something 
'disappear' from the map overnight.


Well, the fear might be there, but the discussion was already here, it 
was not too heated, and that was just my conclusions after the 
discussion. I also wrote the clear TL;DR summary that rendering should 
for now show everything - and then the criticism hit the list, when 
there was not declared to "disappear" anything, let alone over night.


So it has to be something different, I guess, and I still don't know 
what is it?


I don't have a particular idea concerning the orthogonals tags 
mentioned here. But it seems to me they could be discussed better as 
tags in a more general way, then the maintainers of osm-carto could 
propose with their own rendering choice.


That went just like you said: I came with the tagging problem triggered 
by designing rendering, we talked about the tagging problems, and I 
proposed my choice - one for tagging, the second one for rendering.


However it's not that easy nor productive to make everything separate. 
It was parallel discussion in the osm-carto ticket and the arguments 
were not heard on the list. Making more threads doesn't help to 
understand the problem and it's better to avoid it.


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Tagging/rendering relations

[Daniel Koć]

W dniu 03.12.2017 o 18:43, Yves pisze:
I do agree with Christoph here, tag depreciation should be discussed 
outside of the scope of osm-carto.


It would be interesting for me to hear the exact reasons why do you 
think that?


I would also like to know how do you think should we talk about the 
relations between tagging and rendering in an acceptable way?


Daniel, this all thread looks like you want to promote a tagging 
scheme for the primary reason you can't make it look nice on the 
slippy map. That's really not helping tagging discussions!


Rendering is my primary motivation to look at these tags and I see 
nothing wrong with being open about it. This is one of many rendering 
styles and one of many uses of OSM data, and data consuming is also 
important thing to consider. Not the most important, but still something 
to think about.


When designing tags we think about different problems - if it's easy for 
a mapper to tag, if the system is coherent, if the names are clear, so 
thinking about classification is equally valid for me - and it's good to 
know why the classification might be needed at all. I don't talk about 
data analysis, because I don't do that, but I suspect classification 
would help that too.


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Planned rendering changes of protected areas

[Daniel Koć]

W dniu 03.12.2017 o 11:06, Christoph Hormann pisze:


As said before: *do not mix rendering and tagging discussions*.


I don't fully understand what you're suggesting (it's a long, complex 
sentence), but I feel you're  accusing me of something bad. Please note 
that the first point about general osm-carto purpose in the link you 
gave is clear about the link between rendering and tagging:


"It's an important feedback mechanism for mappers to validate their 
edits and helps to prevent unfavorable fragmentation of tag use."


[ 
https://github.com/gravitystorm/openstreetmap-carto/blob/master/CARTOGRAPHY.md#general-purpose 
]


I'm talking about them on their own merits, because they are autonomous 
parts of OSM "ecosystem", but that doesn't mean they are not connected 
in any way, so I talk about these links too.


It's a simple observation: tagging limits and shapes what we render, 
rendering have an influence on the way we use tags. It's better to be 
aware of it to mitigate "tagging for rendering" (which means *tagging 
the wrong way* just to see something, not the feedback loop!) for example.


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Planned rendering changes of protected areas

[Daniel Koć]

Thanks for the comments! They help me to get the bigger picture, which 
is not visible from just the tag names and definitions.


TL;DR summary: I think that for now we should render all the existing 
tags with osm-carto, but make some of them appear earlier to encourage 
smooth migration to a more precise scheme.


W dniu 01.12.2017 o 01:55, Martin Koppenhoefer pisze:

there is no problem with 2 different tags fitting for the same kind of 
thing. These are also different in scope, leisure=nature_reserve is 
for all kind of natural protected areas, while boundary=protected_area 
is for all kind of protected areas.


My general findings are:

1. As I currently understand it, nature reserve is _always_ a type of 
protected area, to begin with.


We were talking on osm-carto ticket with some people about private 
reserves and even when someone told me "it's not about protection!" this 
term was used immediately in the same sentence (or in the next one). =} 
I guess they meant "it's voluntary and not formal", but still it's 
intended as a protection of nature, so it's just a special, weak type of 
protection.


2. The problem seems to be for a mapper to be more precise, since a 
typical survey can reveal a sign with a name "XYZ nature reserve". 
However this is not about just a name.


Boundaries are not visible on the ground easily, so a mapper who draw 
them have to use some other sources and I believe there are more 
informations available. Otherwise the area shape is probably not 
verifiable, which would be bad anyway. And I think all of them are 
areas, not the points (node would mean probably "here is the protection 
area, but exact shape is not shown at the moment"), so boundary is also 
a sure thing.


3. The name tag leisure=nature_reserve states that it's about leisure 
(which of course might be for a given object), but it's always about 
protection. So even if the value have merits, this key assumption is 
wrong in general and misses more important property 
(boundary=nature_reserve has only 35 uses).


4. Another problem is lack of coherent definition of protection other 
than numbers and high-level classes.


The numbers seems to be derived from IUCN scheme ( 
https://en.wikipedia.org/wiki/IUCN_protected_area_categories ), but 
wider: only categories 1-6 is IUCN-based and I don't know about the rest.


Especially class 7 is interesting for us: "*nature-feature area*: 
similar to 4. but /without/ IUCN-level.", so i guess it's for all the 
non-IUCN classified nature reserves. Probably most of the time this 
should be clear from the boundary shape source.


It would be good to have more standardized subtags for common features:
- "nature" - protection_object=* is the same mess as numbers, when 
talking about hierarchy levels, so maybe some subtag like 
"nature_reserve=yes" would be useful
- "private" owner type (not the access type) - 
governance_type=private_landowner would be great (if really used...)
- "voluntary" - but that might be clear from the lack of government or 
international authorities influence


What about the solutions?

My suggestion for osm carto is to look at both tagging schemes for 
nature reserves. I wouldn’t drop support for leisure =nature reserve


In summary, we have 3 popular but overlapping types now:

1. leisure=nature_reserve (77 264)
2. boundary=national_park (16 583)
3. boundary=protected_area (62 016)

Their general properties and relations:

1. has a wrong key, but nice value name, and is a subtype of 3.
2. has a nice value name and a proper key, it's also subtype of 3.
3. is very broad with precise, but not so common name, it also has 
subtypes, which are useful for official classification, but are not 
clear for all the other types of conservation


Therefore I would advice to:

1. Discourage leisure=nature_reserve and make it a subtag of 
boundary=protected_area, like:

    a) nature_reserve=yes - 2 uses
    b) protected_area=nature_reserve - 22 uses
    c) protected_area=nature - 61 uses
if needed, otherwise just use a protect_class=7 or other class if known.

2. Drop boundary=national_park, since it's easy to identify them all and 
they are equivalent for boundary=protected_area + protect_class=2 anyway.


That's about cleaning the tagging. For rendering I would show all of 
them as currently, just using different zoom levels, starting from z8 
currently (this might change in the future, of course):

- z8+: national parks and wilderness areas (both are big by definition)
- z9+: important natural protected areas (class 1-6, with hatched 1a 
probably)

- z10+: other natural protected areas (class 7, maybe also 12, 14 and 97-99)
- z11+: protected areas without class and leisure=nature_reserve

This is just a rough sketch, however it have some nice properties:
- all the existing schemes are visible (boundary=national_park can be 
dropped later)

- more important objects are rendered first
- less precise tagging is rendered late

Another important factor might be 

Re: [OSM-talk] Planned rendering changes of protected areas

[Daniel Koć]

W dniu 30.11.2017 o 17:38, Christoph Hormann pisze:


There are 62k uses of boundary=protected_area and 77k of
leisure=nature_reserve and 31k of the combination - which does not
really support your idea that the latter is used just as a hack.


How would you detect such a hack then?

In my opinion 31k is a serious amount (about a half of both) that is a 
strong suggestion of the problem, at least.



That is frankly just nonsense.  If rendering (or not rendering) features
with leisure=nature_reserve, boundary=protected_area or
boundary=national_park causes visual clutter in a map depends on if and
how you render these features.  That is the responsibility of you as a
map designer.  Blaming a tagging scheme for not being able to do that
without visual clutter is a bit strange.


It's easy - with leisure=nature_reserve you don't have any 
classification system, so you have less tools to make a proper rendering 
decisions. The other solution is guessing or accepting the mess, which 
are poor options for me.



Have you looked at if these classes are actually used consistently at
the moment?  A tagging scheme with ~25 numerical codes as classes with
fairly brief and abstract descriptions is not usually destined for
success in OSM.


We don't need to check every single one of them, probably just selecting 
a nature related subset of them would be enough. Not everything should 
be rendered (like "community life" or "earth-moving area") and even just 
selecting national parks from the rest would be clear win for a start.



4. The new scheme looks like more general than the old one, so it's
all that's we really need.

Which is just another way of saying boundary=protected_area is much less
meaningful than leisure=nature_reserve since the latter at least
specifies it is nature protection while the former does not.


Just look at the classification, there's a cluster of such classes:

https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area#Nature-protected-area


You are also contradicting yourself here - in 2. you say "the old scheme
is too generic" and here you say "the new scheme looks like more
general" - which is it?


By "generic" I mean "lacking details", which is bad.
By "general" I mean "encompassing all of this and more", which is good.


but then drop arguing for certain tagging
ideas based on your perceived needs for rendering.  Tagging decisions
should be based on how mappers can best document their knowledge about
the geography.  Not on what some developers find convenient for
rendering.


In my opinion there's a better tagging scheme for documenting that 
knowledge, that's why I suggested deprecation. But that is just the 
opening of discussion, not the final solution.


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Planned rendering changes of protected areas

[Daniel Koć]

Hi,

I'm thinking about changes in rendering of protected areas on osm-carto 
and I wanted to give community a hint, because it's a popular kind of 
objects. There is a fresh discussion about it from this comment on:


https://github.com/gravitystorm/openstreetmap-carto/issues/603#issuecomment-347879897

In short:

1. Currently leisure=nature_reserve (old scheme) and boundary=* (new 
scheme) are frequently tagged in parallel, and it looks like the old 
scheme is used as a hack just to make it visible on default map.


2. The old scheme is too generic and it causes visual clutter, because 
all of the protected areas are displayed at once.


3. New scheme has many classes defined, which would allow us to fine 
tune the rendering (different zoom levels and only some of them).


4. The new scheme looks like more general than the old one, so it's all 
that's we really need.


Therefore I think rendering of leisure=nature_reserve should be dropped 
on osm-carto, so boundary=* would take over. In this case the areas 
should be tagged with a new scheme to be visible there. That might lead 
to deprecation of leisure=nature_reserve in the future.


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] OSM Tag History updates - call for help

[Daniel Koć]

OSM Tag History is a great service which shows the changes of a given 
tag used in the OSM database. Probably some of you already know it:


http://taghistory.raifer.tech

The problem is however that it needs a full database, which includes tag 
history. The author is not willing to run it himself, so updates are 
manual and not too frequent, which makes the service less useful than it 
could be.


He looks for somebody who "already runs a (daily) updated OSM DB which 
could produce deltas of the counts of tags in their db (for little extra 
processing cost)":


https://github.com/tyrasd/taghistory/issues/10#issuecomment-346945069

If someone is able to do it, please contact him. I would be happy to see 
more frequent, possibly automatic updates, that's why I pass the message.


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] How to show school icons ?

[Daniel Koć]

W dniu 24.11.2017 o 08:57, David SAUVAGE pisze:

What would be the process to change this situation in order for school
icons to be displayed on osm map with the same priority of a library ?


Let me quote what I've just wrote in the osm-carto issue tracker:

"We had a PR which was almost ready, but we were unable to decide how to 
deal with label scaling, because we do this for schools and the icon is 
not to be scaled. There are also other similar objects (like hospitals 
etc), which use the icon, but don't use text scaling, so that would be 
inconsistent.


So the most important thing is to find a rule for all such objects. If 
we have it, rendering education icons could be made quite easily."


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] OpenStreetMap Carto release v4.5.0

[Daniel Koć]

Dear all,

Today, v4.5.0 of the openstreetmap-carto stylesheet (the default
stylesheet on openstreetmap.org) has been released.

Changes include:

Major changes
- Cleaning up low zoom levels (z5-z7):
  - Rendering roads from z6 instead of z5
  - Rendering national parks from z8 instead of z7
  - Rendering railways from z8 instead of z7
- Changing parking color from yellow to gray

Changes
- Unified rendering of leisure=fitness_station and leisure=fitness_centre
- Rendering of military=bunker
- Rendering all station buildings as major buildings
- Text wrapping for station labels
- Changing windmill color from amenity brown to man_made gray
- Some other documentation and code changes

Thanks to all the contributors for this release.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.4.0...v4.5.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

Re: [OSM-talk] Serious JOSM performance degradation

[Daniel Koć]

W dniu 11.11.2017 o 22:55, john whelan pisze:

>17MiB

Interesting file size.  What is a MiB?


https://en.wikipedia.org/wiki/Mebibyte

--
"My method is uncertain/ It's a mess but it's working" [F. Apple]

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Hillshading on OSM maps

[Daniel Koć]

I was thinking about hillshading on the osm-carto as part of the low 
zoom improvement process. The idea was quickly rejected:


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

but I wanted to look deeper and ask about your experiences with 
hillshading on the maps using OSM data (like for example cycling layer 
on OSM.org):


1. What kind of hillshading data is used and what is the quality on low, 
middle and high zoom levels (SRTM-based NaturalEarth maybe - general or 
manually edited)?


2. Did you find any problems with hillshading (like peak or saddle being 
placed differently than shading suggests)?


3. What do you think about using OSM hillshading "fork" which could be 
editable somehow to follow OSM data (of course it doesn't belong to OSM 
database, since it's a raster data, not a vector one)?



--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Woods vs Forests

[Daniel Koć]

W dniu 02.11.2017 o 07:14, Warin pisze:

On 02-Nov-17 02:31 PM, Stephane Goldstein wrote:


Do you have any other words that smean tree planting, growing and
then harvesting?? And don't mean anything else?
The closest I have is 'forestry'.


landuse=forestry is a good option as well.


I'd like one word that includes harvesting of the trees as well.


Currently there's quite popular tag for such activity:

https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dlogging

--
"My method is uncertain/ It's a mess but it's working" [F. Apple]

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Label language on the Default stylesheet

[Daniel Koć]

W dniu 01.11.2017 o 14:28, Oleksiy Muzalyev pisze:

A would-be future vector map, probably, is not a a good solution, as 
it does not use the principle of precalculation. The Latin language 
has been used for centuries in science (including geography and 
cartography). Its popularity is growing nowadays.


One can deploy l10n osm-carto fork with Latin:

https://github.com/giggls/openstreetmap-carto-de/tree/upstream+l10n

or just use the English-enhanced map:

https://tile.iosb.fraunhofer.de//#map=5/30.1198/33.2703/3

I also think that vector name overlay is needed anyway, no matter if and 
when we'll have full vector map.


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Label language on the Default stylesheet

[Daniel Koć]

W dniu 01.11.2017 o 14:36, Andy Townsend pisze:

On 01/11/2017 13:28, Oleksiy Muzalyev wrote:
Still, the OSM map remains unusable on the global scale. For 
instance, I read an article about the new railroad North-South. I 
wanted to see it on the OSM map but I could not even find Iran on the 
map. 


Works for me:

http://www.openstreetmap.org/#map=6/31.887/52.844=T


Only to some degree - try to see Beijing here on z5 and z6:

http://www.openstreetmap.org/node/25248662#map=5/38.273/117.400=T

You can report it to Andy, of course, but I'm sure there are more cases 
like this.


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Woods vs Forests

[Daniel Koć]

W dniu 30.10.2017 o 18:13, Martin Koppenhoefer pisze:
one tag for what? An area with trees? A forest? How would you define 
"forest"?


"Although /forest/ is a term of common parlance, there is no universally 
recognised precise definition, with more than 800 definitions of forest 
used around the world."


[ https://en.wikipedia.org/wiki/Forest#Definition ]

I think it's hopeless for us to coin good definition.

FWIW, there's already a compatible tag to say: "area with trees", and 
that is landcover=trees.


+1 - this one is clear for me.

--
"My method is uncertain/ It's a mess but it's working" [F. Apple]

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] MapRoulette task creation

[Daniel Koć]

I have two ideas for MapRoulette, but I haven't tried to set my own 
challenge yet and the main problem is that I don't know how to prepare 
the data, since both are about nested areas:


1. Checking if amenity=place_of_worship way without building=* tag 
inside another amenity=place_of_worship or landuse=religious way needs 
adding building=* tag (very common omission, easy to see on aerial photos).


2. Checking the outer part of relation tagged with water=* - probably 
only relation should be tagged with water=* (common error which hides 
the inner parts, like islands/islets).


Could anybody help me with that?

--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Wiki problems (was: weeklyOSM #379 2017-10-17-2017-10-23)

[Daniel Koć]

Could we please use more descriptive subject for discussing wiki issues?


W dniu 29.10.2017 o 08:45, Simon Poole pisze:

Regardless of what measures I think are appropriate, it is clear that if
something doesn't change the net result will be a perma-ban which has
been pointed out to him multiple times and will not come as a surprise .


1. I have no personal issues with Verdy_p, but it's telling me a lot 
that also few people from the Polish OSM community thinks he deserves 
it. Nobody is proposing to ban anyone else, let alone permanently, so it 
means that he has serious problems dealing with people, which is bad - 
even if he was always right.


2. I have however a problem with wiki categories and pages not being 
refreshed, even using "purge" button. Do you know where this problem 
comes from?


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Woods vs Forests

[Daniel Koć]

W dniu 27.10.2017 o 08:36, Warin pisze:


The landuse key is clearly to tag the use of the land by humans.


It's also to indicate use of the water, hence it's not 100% clear and I 
understand why some people don't like it.


The natural key is unclear - it seams to be for both things made by 
nature and things made by man! To me this confused all and the key 
should be discouraged.
It should be replaced by the keys landcover and landform, these have 
no implication of human or nature but simply describe the type of 
feature.


Let's look at natural=tree - it doesn't matter if the tree was seeded by 
man or by natural means, the tree is natural object, which was not 
created by man (even GMO is about _modyfying_, not creating). There can 
be however man_made=tree - we have a popular artwork in Warsaw, which is 
a palm made of plastic (tagging has changed, but it's a nice example):


https://en.wikipedia.org/wiki/Greetings_from_Jerusalem_Avenues
https://www.openstreetmap.org/node/1795659661

Landcover is neutral (what one can see on the surface). I like it 
because it's closest to the "ground truth", and is very useful when we 
don't know more details. However we could promote "surface" tag as a 
primary and it would also make sense for me (currently it's defined as 
additional tag: "used to provide additional information about the 
physical surface of roads/footpaths and some other features").


I have no idea what "landform" can be, so I don't have an opinion on that.

However "natural" key for trees ( 
https://taginfo.openstreetmap.org/tags/natural=trees maybe?) sounds 
perfectly valid for me.


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Topology rules

[Daniel Koć]

W dniu 26.10.2017 o 23:36, Warin pisze:
While natural=wood renders, I also tag them as landcover=trees as that 
is more truthful of what is there.
So these tree areas get two tags from me until such time as landcover 
is rendered then I will remove the natural tag.


If you mean standard tile layer (osm-carto), landcover=* tag is far from 
being accepted:


https://github.com/gravitystorm/openstreetmap-carto/issues/2548#issuecomment-330002296

--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Welcome_to_OpenStreetMap_users ?

[Daniel Koć]

W dniu 25.10.2017 o 07:42, Maarten Deen pisze:

On 2017-10-25 07:31, Daniel Koć wrote:

W dniu 25.10.2017 o 07:08, Roland Olbricht pisze:
See 
https://wiki.openstreetmap.org/wiki/Welcome_to_Wikipedia_users#Original_research_always_wins


Why is this page named "Welcome_to_Wikipedia_users"? Can we just move
it to "Welcome_to_OpenStreetMap_users" or there are some not obvious
problems with that?


You have to read it as "a welcome to wikipedia users", a greeting that 
is extended from the OSM community.


This makes sense, thanks!

--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Welcome_to_OpenStreetMap_users ?

[Daniel Koć]

W dniu 25.10.2017 o 07:08, Roland Olbricht pisze:
See 
https://wiki.openstreetmap.org/wiki/Welcome_to_Wikipedia_users#Original_research_always_wins


Why is this page named "Welcome_to_Wikipedia_users"? Can we just move it 
to "Welcome_to_OpenStreetMap_users" or there are some not obvious 
problems with that?


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] How to create custom online map from OpenStreetMap

[Daniel Koć]

W dniu 23.10.2017 o 22:06, Andy Townsend pisze:

On 22/10/2017 18:47, Carlos Cámara wrote:
I would like to create a custom map for online use that loads OSM 
data but displays it in different ways as the standard, cyclemap, 
transport... layers.


The most important question is: how do you want it to be different? Like 
trying completely new toolset (to try out technologies), just a style 
tuning (to change the look of a few things, like colors or labels) or 
something more specific?


Another couple of resources to look at (if you think you'll go down 
the "Mapnik" route):


To create a tile server with the same stylesheet as OSM's "standard" one:
https://switch2osm.org/manually-building-a-tile-server-16-04-2-lts/


If you don't need a full-blown server with the whole planet for many 
concurrent users, you can use a Docker-based container with Kosmtik as a 
tile server:


https://github.com/gravitystorm/openstreetmap-carto/blob/master/DOCKER.md

--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] OpenStreetMap Carto release v4.4.0

[Daniel Koć]

Dear all,

Today, v4.4.0 of the openstreetmap-carto stylesheet (the default
stylesheet on openstreetmap.org) has been released.

Changes include:

Major changes
- Rendering inland water areas and labels from z0
- Rendering island and islet labels earlier

Changes
- Rendering of amenity=marketplace
- Rendering of landuse=religious
- Rendering shop=pastry like shop=confectionery
- Rendering of addr:unit
- Rendering natural=bare_rock earlier
- Rendering elevation also on polygon alpine_hut and shelter
- Introducing Noto Sans Arabic
- Rendering icon for slipway ways
- Better minimal distance between housenumbers
- Moving aeroways to their own layer
- Creating amenity POI categories
- Some other documentation and code cleaning

Thanks to all the contributors for this release, including tpikonen,
a new contributor.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.3.0...v4.4.0

As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues


--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Hardware partnership and projects wishlist

[Daniel Koć]

Hi,

I'm looking for partners with hardware resources in Poland to use it for 
some interesting OSM-related projects.


I've made basic research with OSMF, French and German pages about 
hardware and network connectivity and it looks like they collaborate 
with academic and business world:


- https://hardware.openstreetmap.org/thanks/

- https://www.openstreetmap.fr/soutiens

- https://wiki.openstreetmap.org/wiki/FOSSGIS/Server

What are your experience with such collaborations in different places 
(not only in GB, FR and DE)? Any advices or warnings?


I have few ideas what could be done with enough hardware resources 
available, but I'm also interested what other people think could be the 
most wanted and useful projects for the OSM community?



--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Island/islet area tagging

[Daniel Koć]

Hi,

We'll probably start to render island/islet labels earlier (if the code 
will be merged, of course), so I've made a short info with renderings on 
z4-z6 showing only island names on the planet:


https://github.com/gravitystorm/openstreetmap-carto/pull/2890#issuecomment-336664545

It looks like some of the biggest islands are not tagged this way - 
probably because they are already visible as a land and tagged as admin 
entity, but not all the maps are political, so please add the proper 
tagging to make island/islet dataset more complete.



--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk