Re: [OSM-talk] When two bots go to war

[Paul Norman]

They have edited it back with 
https://www.openstreetmap.org/changeset/141281494. I've left a changeset 
discussion comment asking why, and asking for a link to the required 
documentation and consultation.


On 2023-09-14 12:36 a.m., Cj Malone wrote:

On Tue, 2023-09-12 at 15:06 +0200, Snusmumriken via talk wrote:

My speculation is that Distriktstandvården (a chain of dental
clinics)
has taken "ownership" of "their" nodes and once a day check that the
values in osm database correspond to that of their internal database.

I've added a more specific website tag to test this. If they restore it
(Probably 03:00) to the generic home page I agree with you. They need
to be informed that 1) there data needs improving (eg covid opening
hours, POI specific not brand specific contact details) 2) they don't
own these nodes, other people can edit them.

CJ

https://www.openstreetmap.org/changeset/141243391


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


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

Re: [OSM-talk] Announcing State of the Map 2024: Join us in Nairobi and online on 6-8 September 2024!

[Paul Norman]

On 2023-08-14 10:56 a.m., Federica Gaspari wrote:


Following the good feedback for State of the Map 2022 Firenze, the 
upcoming State of the Map 2024 will once again be held in a hybrid 
format. Building on the valuable lessons and experiences from the 
previous events, the SotM Organising Committee is committed to making 
this edition even more accessible to everyone who wishes to partake in 
this grand celebration of open mapping, sharing passionate voices with 
the entire community.




A lot of work has been done at mapping for minorities, including 
attributes that are relevant for LGBTQ+ people. Would a mapper be able 
to present their work at the conference? Would they able to participate 
remotely and have their talk seen in-person at the conference?


Government travel advisories state LGTBQ people are routinely harassed 
by the police. If this happens at the conference, how would you enforce 
the Code of Conduct which prohibits LGTBQ harassment?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Announcement: OpenAirportMap

[Paul Norman]

On 2023-02-21 12:52 a.m., Stephan Knauss wrote:
I wonder how you implemented the map access. After hopping to the 
second airport i am receiving status 429 from tile.openstreetmap.org.
I have not browsed around the OSM map before, so I wonder how many 
requests you are doing to trigger here a policy block on the tile 
server that fast. 


Rate limiting for 429 requests is not done on a website basis, but on a 
per-IP basis. We're still tuning the thresholds, and I've adjusted them 
after reviewing the usage that lead to your block yesterday and changed 
the thresholds.


The zoom, pan, and zoom that Leaflet does (flyTo API, I assume) to move 
from location to location loads about 2000 tiles on a 4k display, and 
could load more depending on resolution settings. This is more than I 
had expected when I set the limits, so I've adjusted the our settings to 
allow it.



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

[OSM-talk] OpenStreetMap Carto release v5.7.0

[Paul Norman]

Dear all,
Today, v5.7.0 of the OpenStreetMap Carto stylesheet (the default
stylesheet on the OSM website) has been released. Once changes are
deployed on openstreetmap.org it will take couple of days before
all tiles show the new rendering.
Changes include
-Unpaved roads are now indicated on the map (#3399)
-Country label placement improved, particularly for countries in the
  north (#4616)
-Added elevation to wilderness huts (#4648)
-New index for low-zoom performance (#4617)
-Added a script to switch between script variations for CJK languages 
(#4707)

-Ordering fixes for piers (#4703)
-Numerous CI improvements
Thanks to all the contributors for this release, including wyskoj, 
tjur0, depth221, SlowMo24, altilunium, and cklein05, all new contributors.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v5.6.2...v5.7.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] Upcoming downtime on 2022-01-22

[Paul Norman]

On 2022-12-23 12:11 p.m., Paul Norman wrote:

Dear OpenStreetMappers,

On Sunday January 22nd 2022 between 10:00 and 15:00 UTC/GMT the API 
database servers will be unavailable due to maintenance. You can see 
this in your local time zone at 
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenStreetMap+API+Maintenance&iso=20230122T10&p1=%3A&ah=6



This should, of course, be 2023, not 2022. The link is correct.


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

[OSM-talk] Upcoming downtime on 2022-01-22

[Paul Norman]

Dear OpenStreetMappers,

On Sunday January 22nd 2022 between 10:00 and 15:00 UTC/GMT the API 
database servers will be unavailable due to maintenance. You can see 
this in your local time zone at 
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenStreetMap+API+Maintenance&iso=20230122T10&p1=%3A&ah=6


We are planning to upgrade the software which runs the main 
OpenStreetMap database. Unfortunately, we cannot do this without some 
downtime.


The following services WILL be affected:

- www.openstreetmap.org web site WILL NOT allow edits,
- API will NOT allow map editing (using iD, JOSM, etc), and
- replication updates will be paused (minutely updates and changeset 
replication).


We expect that the database upgrade will not take the full duration, and 
we will try as far as possible to keep the API available in read-only 
mode, but the API may be briefly unavailable.


At times you may be unable to login to services which requires 
openstreetmap.org authentication (e.g. community, forum, and help)


Other OpenStreetMap provided services should not be affected except for 
login - all of the following are expected to function normally:


- Map viewing on www.openstreetmap.org
- nominatim (search)
- standard tile layer
- wiki
- taginfo
- mailing lists
- Distribution of planet file and existing diffs

Services not run by the OSMF will not be impacted, except there will be 
no updates from OSM.


Technical details are at 
https://github.com/openstreetmap/operations/issues/548



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

Re: [OSM-talk] Building a tile-server

[Paul Norman via talk]

On 2020-07-01 3:28 p.m., Martin Koppenhoefer wrote:


sent from a phone


On 1. Jul 2020, at 23:26, Paul Norman via talk  wrote:

In general, work_mem=128GB is good with most styles.



Paul, he wrote he had 32GB of RAM, should one assign more work_mem than there 
physically is on the machine?

I am asking because I thought that the value of work_mem could be used multiple 
times and the sum should not exceed the actual RAM, but maybe this isn’t how it 
works?

Cheers Martin



Whoops, that should be 128MB.


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

Re: [OSM-talk] Building a tile-server

[Paul Norman via talk]

On 2020-07-01 1:42 p.m., Frederik Ramm wrote:

+ I have seen a couple of different postgresql config suggestions. Is
there a one-size fits all or should I tailor it more to my server's
configuration.

Most configs you see will be for earlier Postgres versions and hence not
necessarily valid for Pg 12. Switching off everything that has to do
with "safe writing", e.g. fsync, certainly makes sense (you have to
restart the import anyway if you suffer from power failure mid-way, no
use in setting up Postgres to avoid data loss when writing).



The two settings you should adjust are work_mem and maintenance_work_mem.

In general, work_mem=128GB is good with most styles. I haven't 
experiment with more. If you have the RAM, maintenance_work_mem=4GB 
would be plenty.


Do not adjust synchronous_commit. osm2pgsql turns it off for the import, 
and this will override your setting.


Do not adjust fsync. synchronous_commit gets you the performance gains.

You may want to increase checkpoint_timeout and 
checkpoint_completion_target, but these offer minor gains at mosts.


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

Re: [OSM-talk] [OSM-dev] OpenStreetMap Carto release v5.0.0

[Paul Norman via talk]

On 2020-03-19 1:18 a.m., Hartmut Holzgraefe wrote:

On 19.03.20 02:07, Joseph Eisenberg wrote:

All style users who upgrade to v5.0.0 should re-import the rendering
database so that the changes to lua transformations will take effect.

As I'm running a "render as many styles as possible" installation based
on a "hstore all, hstore only, vith views on top to provide actual
expected schema" on print.get-map.org, what influence would this have
on the older styles?

"An update to Lua tag transforms, setting line vs polygon decisions
for new tags"

Is this really just about "What should end up in which table,
planet_osm_line vs. planet_osm_polygon?

In that case it would probably not matter at all ...?


There are a few things we fixed that will result in bugs if you render 
osm-carto 5.0.0 against a 4.x database, principally with z_order. I 
don't know if the reverse is true.


As time goes on and we render different features running 5.x against a 
4.x database will result in missing features.



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

[OSM-talk] OpenStreetMap Carto release v5.0.0

[Paul Norman via talk]

Dear all,

Today, v5.0.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
- An update to Lua tag transforms, setting line vs polygon decisions
  for new tags

- Added upper way_area limits to most features using ST_PointOnSurface
  to avoid performance problems from large polygons

- Moved MSS files into their own directory

- Removed rendering of power=cable features

- Removed overlay pattern for natural=sand

- Reduced landcover fading at mid-low zoom levels

- Removed rendering of barrier=kerb

Thanks to all the contributors for this release.

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

[OSM-talk] OpenStreetMap Carto release v4.22.0

[Paul Norman via talk]

Dear all,

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

- Shop label fixes and use ST_PointOnSurface for building label placement

  This fixes some bugs and makes building label placement consistent 
with shop

  label placement.

- Use `cache-feature: true` to improve performance of layers with 
attachments


- Use retail colour fill on malls

- Drop `highway=steps` from zoom 13

  This makes step rendering consistent with footways

- Render `place=locality` from zoom 16

  This fits current usage of the tag and what it is normally tagged on.

- Render `natural=bay` from linear ways

- Render administrative boundary labels from relations only

- Stop rendering natural=marsh

  It is recommended marshes are tagged with `natural=wetland` + 
`wetland=marsh`


- Use a whitelist for barrier rendering, and render `historic=citywalls` 
like

  `barrier=city_wall`.

- Support new Tibetan font name

  Noto has renamed Noto Sans Tibetan to Noto Serif Tibetan. The old name is
  still supported.

- Code cleanups to increase reuse and improve consistency


Thanks to all the contributors for this release, including daveol and
btwhite92, new contributors, and jeisenbe, a new maintainer.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.21.0...v4.22.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] [Osmf-talk] OSMF Board face-to face meeting: Suggest the topics and issues that matter to you

[Paul Norman]

On 2019-05-09 3:48 a.m., Christoph Hormann wrote:

On Thursday 09 May 2019, Dorothea Kazazi wrote:

The OSMF Board is going to have a face-to-face meeting in Brussels
later in May for strategy and planning and you can suggest the topics
and issues that matter to you:

https://osmf.limequery.org/489698?lang=en

Will the answers be published?



We're adding a checkbox to cover that.

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

[OSM-talk] OpenStreetMap Carto release v4.21.0

[Paul Norman via talk]

Dear all,

Today, v4.21.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
- Removed unused world_boundaries-spherical.tgz file from scripts

- Switch to osmdata.openstreetmap.de for water & icesheet shapefiles

- Started using ST_PointOnSurface for some label placements

- Adjusted index for military areas

- Adjusted starting zooms for labeling of administrative areas.

- Revert rendering of healthcare key

- Stop place some place labels when the objects become too big or at 
high zooms.


- Only render capes as points and render them like other points.

- Only render ferry lines from ways, not relations

- Improved developer internal documentation



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


For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.20.0...v4.21.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] iD influencing tagging

[Paul Norman via talk]

JOSM has also done the same, and gone farther with creating new tags on its issue tracker.Developing an editor requires making decisions and having opinions on OSM tagging. This in turn means getting it wrong sometimes.On Apr 7, 2019 5:43 AM, John Whelan  wrote:
I note that the 
matter has been raised in talk-de and mentioned in osm weekly.Tagging
 is not always easy, but I do have concerns when iD is so commonly used 
but the recommended tags do not align with OpenStreetMap I'll say 
normals.  Specifically one of my concerns is a semi-detached 
house is not recognised in iD only the more general tag house.JOSM
 I think is much more open than iD but given the way OpenStreetMap 
functions I suspect ID is a much more closed environment.  For 
example JOSM has the buildings_tool plugin, Africa has a large number of
 odd shaped buildings mapped in iD.Thoughts ladies and 
gentlemen?Thanks John-- 
Sent from Postbox

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

Re: [OSM-talk] We need to have a conversation about attribution

[Paul Norman via talk]

On 2019-02-28 2:35 p.m., Richard Fairhurst wrote:


In recent years some OSM data consumers and "OSM as a service" 
providers have begun to put the credit to OpenStreetMap behind an 
click-through 'About', 'Credits', 'Legal' or '(i)' link. Examples:


https://docs.mapbox.com/help/img/android/android-first-steps-intro.png
https://www.systemed.net/osm/IMG_1846.PNG



In my mind what makes these examples particularly egregious is how they 
find room for image logos. If there's room for a Mapbox or Tomtom logo 
like in the images above, there's room for (c) OpenStreetMap


With maps like this, I would expect a "reasonably calculated" 
attribution to have OSM with at least the prominence of other companies.



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

Re: [OSM-talk] HTTPS all the Things (Automated Edit)

[Paul Norman via talk]

On 2019-02-26 6:05 a.m., Frederik Ramm wrote:

Hi,

when I first read about this planned edit, I was critical too; I
thought, "ah, another eager youngster wanting to make the world a more
secure place by telling everyone else how they ought to conduct their
business".

But if I haven't totally misunderstood this, then the proposal will only
replace a http:// by a https:// pointer if the site operator himself has
added that redirect in their web server configuration.



I find myself also in cautious favour of the edit as explained and that 
it will slightly improve the database overall.



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

Re: [OSM-talk] Organised Editing Guidelines now officially live

[Paul Norman]

On 2019-01-10 10:19 a.m., Christoph Hormann wrote:

Since it is on the OSM wiki and there is no statement indicating
otherwise does this mean we can start improving the guidelines now?;-)



If you can edit them to be closer to the text approved by the OSMF board ;)

We just discussed this internally, the reason we've got them on the 
publicly editable wiki even though it's a policy is the number of links 
to/from the page make it more useful on the this wiki instead of the 
OSMF one.



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

Re: [OSM-talk] Help - how to get rid of wrong image in wiki?

[Paul Norman]

On 2018-12-19 11:25 p.m., Maarten Deen wrote:
And the image is not entirely wrong, it's an example of a reversible 
oneway street.

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



The Lions Gate Bridge and Stanley Park causeway are not one-way. The 
middle lane switches direction, but there is always at least one lane in 
each direction.



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

Re: [OSM-talk] Licence for Sentinel Satellite images

[Paul Norman]

On 2018-12-17 11:13 a.m., John Whelan wrote:
My understanding was a benediction by the Legal Working Group can be 
taken as the highest "official" approval although I understand there 
is a small backlog of licenses awaiting.



The LWG has not historically looked at data licences. There have a been 
a couple cases like CC BY 4.0 where there have been external reasons for 
them to get involved, but they have been the exception, not the rule.



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

Re: [OSM-talk] Distribution of OSM ids could be much more useful!

[Paul Norman]

On 2018-11-25 5:50 AM, Victor Shcherb wrote:

What do you think?


It would be terrible for most software that I am aware of that can 
process the full planet. Current assumptions about density would be 
broken, vastly inflating memory usage and slowing down processing.


The benefits aren't great as I see them. Using a z-order curve encoded 
in the first 30 bits will help cache locality, but like all z-order 
curves, it doesn't guarantee that two nearby places in 2d space have 
nearby places on the curve. This means that an implementation still 
needs to be able to search through the nodes for nearby ones.


Two other problems come to mind. The first of these is implementation. 
IDs are a PostgreSQL bigserial, and to write something custom that 
assigns IDs based on location would be difficult as it would need to get 
MVCC right. The second is the number of bits. Some software is limited 
to 53-59 bits, and other to 63 bits. We're using about 75% of 33 bits 
right now.


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

Re: [OSM-talk] Multiple errors in the same location

[Paul Norman]

On 2018-11-21 2:29 PM, Jem wrote:

> It is a CanVec import from 4 years ago

Is there subtext to this? I saw the weird natural=wood CanVec features 
yesterday (polys cut up into quadtrees) and wondered about its 
validity. Is the CanVec import notable for being problematic?


Yes. CanVec is built from multiple sources, so there can be different 
issues in different regions. The issues here with overlapping forest and 
water geometries and overlapping data with existing data are common to 
many CanVec imports. Four years ago is recent enough that the user 
should have known that they needed to fix these problems. Where I live 
there are problems like some data being 40-50 years old.


From a practical side, when fixing an area, my first step is generally 
to delete any data bears no resemblance to reality. In this case, if I 
wanted to fix just around this lake I would do it by


1. deleting whichever of the water traces is worse;
2. getting any obvious water improvements;
3. deleting the forest inner way; and
4. adding the water as an inner to the forest multipolygon relation.

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

Re: [OSM-talk] osm2pgsql diff application with filtered OSM data

[Paul Norman]

On 2018-11-11 7:53 AM, Nick Whitelegg wrote:



After thinking about this, I realised that I don't really want to 
update _all_ the data that often. The only thing I need to update on a 
weekly basis is the footpaths (I'm not so bothered if say the roads, 
or the pubs are a year out of date - as long as newly mapped footpaths 
appear quickly). So what I'm now doing is just doing an osmosis 
extract of paths weekly, deleting all data in the DB which I class as 
a 'path' and repopulating in amend mode.




This will leave your site down between the delete and import of new data.

It's also going to be fragile, because using append mode with a file 
that isn't a diff isn't supported, and if the area has a lot of 
footpaths, it'll be slower, since append has to do more work.


If you match the SQL delete and osmosis filtering carefully you 
shouldn't get too many errors, but you've probably got some to do with 
updates and changing object types.


As long as you're aware of these problems and it works for your needs, 
I'd say to go for it.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] osm2pgsql diff application with filtered OSM data

[Paul Norman]

On 2018-11-08 6:34 AM, Nick Whitelegg wrote:


At the moment I download full planet extracts about every 6 months. 
However, due to the limitations of my server, I filter out (with 
osmosis) a lot of stuff I don't need so that I am basically left with 
roads, footpaths, natural features, water features and selected POIs.



I'd like to move towards a system which applies diffs from geofabrik 
instead, and applies them regularly (daily or weekly) with osm2pgsql.



My question is this; given that not everything in the diff will be in 
my database (as I filter out what I don't need during the import 
process), will osm2pgsql apply the diff successfully or will it 
complain that not all features in the diff are in my database?




I can think of four ways to do this, all which have a different balance 
of correctness, performance, and ease of use.


There are two "right" ways to do this. The first one is to re-import 
every week. Because imports without slim tables (either --slim --drop or 
no --slim) are faster, this is a good option and needs less space than a 
database able to consume diffs.


The second right way involves keeping two files, one with the current 
full data, and one with the filtered data. Call these "planet.pbf" and 
"planet-filtered.pbf". Then when updating create "planet-new.pbf", 
filter it to get "planet-filtered-new.pbf", create a diff for the 
differences between "planet-filtered-new.pbf" and "planet-filtered.pbf", 
and apply that diff to the database. Then replace the old files with the 
new ones. This will keep the database correct.


A "wrong" way to do it is to import the filtered data, apply updates 
directly, and periodically delete data from the DB. The problem with 
this is that if someone adds one of the selected POI tags to a building 
that you have filtered out, osm2pgsql won't have the node data to create 
a geometry. This might be acceptable, depending on use case.


A less wrong way would be to modify your filtering so no nodes are 
filtered out. There are still potential errors with relations, but these 
are less common. If you're doing the planet or a large extract and using 
flat nodes there's no storage penalty for having all the nodes.
___
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?

[Paul Norman]

On 2018-08-10 1:06 PM, Blake Girardot HOT/OSM wrote:

Learning the real world use cases and where the proper technological
solutions work and if there really genuinely are places where dynamic
generation is just not possible.

This seems totally in line with things done in the past and should
work well here.


Speaking as a developer, it's much easier to add PlusCode support 
properly than to try and parse another address tag. Don't add them 
thinking it makes it easier.


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

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

[Paul Norman]

On 2018-07-18 11:04 AM, Andrew Hain wrote:
Will there be a local team or does whatever can’t be done remotely 
need a visit?


For the install there will be two people traveling with the equipment, 
and I've reached out to some locals that were recommended. We should 
have enough people to get it done in the two days scheduled, but more 
hands are welcome.


If you're a local with the technical background to help install servers 
or experience moving equipment and interested and available on Wed July 
25th or Thurs July 26, please let me know off-list. The data centre is 
Equinix AM6 in De Omval, Oost, Amsterdam: 
https://www.openstreetmap.org/way/460515888


Long-term, the remote hands are capable of performing most tasks, 
including installing new servers. Local help would still be useful, so 
if you're interested, also let me know off-list.


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

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

[Paul Norman]

On 2018-06-29 3:38 AM, Max wrote:
That is inflating the OSM database with something that Wikidata has 
solved already in a much better way. Why would someone from wikimedia 
recommend to create a less mentainable version of their database?




Wikidata has 412978 "thoroughfare" items. OSM has 121 million highway 
ways. These don't correspond 1:1 with each other, and it'd be 
interesting to get an exact comparison, but OSM even records more 
distinct street names than Wikidata records total streets. Companies 
like Mapbox have been trying to improve coverage with paid contractors 
filling out spreadsheets of names, but that comes with its own problems, 
and clearly hasn't made Wikidata a substitute for OSM when it comes to 
geographic names.


On a technical level, processing Wikidata data to work with map data is 
harder than processing OSM data, and lacks the standardized practices 
and documentation.


Lastly, when it comes to names in OSM as opposed to translations or 
transliterations, we should want them improved in OSM. This is, after 
all, an OSM mailing list.


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

[OSM-talk] OpenStreetMap Carto release v4.12.1

[Paul Norman]

Dear all,

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

The sole change is dropping rendering of the surface tag because the method
used was causing unacceptable performance problems. Anyone running v4.12.0
should immediately update, particularly if they have a large database.

You can view the previous changes with v4.12.0 at 
https://github.com/gravitystorm/openstreetmap-carto/blob/master/CHANGELOG.md#v4120---2018-06-22


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] OpenStreetMap Carto design

[Paul Norman]

On 2018-06-29 2:48 AM, James wrote:

So what is intended to replace CartoCSS? Vector tiles?


CartoCSS is a styling language, vector tiles is an architecture choice. 
You can use CartoCSS with vector tiles, as the Cycle Map and Transport 
Map layers on osm.org do, or you can use CartoCSS with just conventional 
Mapnik, like the Standard and Humanitarian layers do.


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

Re: [OSM-talk] OpenStreetMap Carto design

[Paul Norman]

I've been involved in OpenStreetMap Carto less and less, partially 
because I work with CartoCSS setups enough for work.



On 2018-06-29 2:06 AM, Christoph Hormann wrote:

And you are wrong that "nobody seems to be even noticing" complexity of
the roads code.  At least Lucas, Paul and me have a very good idea
about this.  And the unpaved roads rendering is not the problem here,
the problem is the complexity of roads rendering in general.


I had a go at fixing the roads code with 
https://github.com/gravitystorm/openstreetmap-carto/pull/2869, but 
didn't have free time. Based on that work, I'd estimate that the roads 
code is twice the size and complexity of what it needs to be.


With the surface code merged, I would be unwilling to tackle a cleanup 
like that. I like the surface code as a technical demo, but find it's 
too much complexity for the style in a part of the style which is 
already difficult to understand.


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

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

[Paul Norman]

As part of my Wikimedia Foundation work, I'm working on labeling in
multiple languages using OSM data. We've run into an issue, and it's not
clear how to best solve it.

It is sometimes recommended that when you add a name in another language
you also indicate the name in the local language by adding a suitable
name:* tag at the same time. For example, if adding "name:fr=Londres" to
London, you would also add "name:en=London" if it weren't present.

This practice is not widely followed. For example, 3% of the roads with
names in multiple languages in the western US have a name:en tag.[1]
Cities are better, but still only 30% of cities and towns with names in
multiple languages have a name:en tag. For the same criteria in China
and with Chinese, it's 30% of roads and 75% of cities.[2]

This is a problem for displaying labels. Proper display of labels is
more than just showing the name in the language the user requested and
falling back to the name=* tag. It requires falling back through
multiple languages. For example, if someone requests a map in
Luxembourgish, you would show German labels where places and objects
have no Luxembourgish names. There are similar situations for French
Creoles and many regional and minority languages.

We'd like to be able to do more. Specifically, we'd like to always show
labels in the user's script if possible. For example if a French user is
viewing a map of India, they're more likely to be able to read an
English name than one in a Dravidian language, Hindi, or Bengali. The
common lack of a name:* tag for the primary language while having other
name:* tags makes this impossible.

There aren't any great solutions. Fixing this in software doesn't work
well because it requires regional processing of what are increasingly
small regions as you get to less used languages. Language detection from
the tag value is fragile and introducing magic logic. This really needs
addressing on the OSM data side.

If there's agreement that there is a problem here, I could look at
preparing a mechanical edit or MapRoulette challenge to add name:* tags,
e.g. adding name:en to objects in the US with other name:* tags, and
adding name:zh in China. As an estimate, this would be 115k changes in
China, touching 28% of roads there.

[1]: https://phabricator.wikimedia.org/T192662#4151714
[2]: https://phabricator.wikimedia.org/T192662#4147291


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

Re: [OSM-talk] Help me build an OSM Community Index

[Paul Norman]

On 3/31/2018 5:25 AM, Bryan Housel wrote:
a `.geojson` file to describe where the region where it is active. 
 (multiple resources can share a .geojson file)


I'm having trouble figuring out what a sensible region is for the 
meetups in Vancouver and the Pacific Northwest.


Our meetups are along the coast, but I don't believe there are any other 
meetups for a few hundred km as you go inland. Closer to home, I'd 
consider Chilliwack part of our region in many ways, but it's 100km from 
there to our normal meeting place. This makes it too far to suggest, 
because it's a 90+ minute drive. Where would I cut it off?


Going up and down the coast, we have a different problem. Vancouver, 
South-Central Salish Sea, and Seattle all share a meetup organization, 
and have overlap in members. The boundaries here are fuzzy.


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

Re: [OSM-talk] Is this legal to what philly.com is doing?

[Paul Norman]

On 2/22/2018 8:03 PM, James Mast wrote:

http://www.philly.com/philly/news/politics/will-republicans-impeach-pennsylvania-supreme-court-justices-20180222.html

(ignore what the article is about)


Just happen to see a thumbnail and clicked on the article since I 
noticed the OSM base map.  Nowhere that I can find does it give credit 
to OSM for the use of it.



Now, the part to where I was curious if this was legal (sans the lack 
of credit), is that they are 'selling' the uploaded image.  Is that 
allowed currently under the license that OSM has?





Yes. They need to either be attributing OSM, or if the image is taken 
from an osm.org render, attributing OSM and licensing it CC BY-SA.


A key feature of open licenses is that they do not discriminate by field 
of use, which includes commercial use. Someone who purchased the image 
can either reuse the underlying data under the ODbL, or, in the case of 
a CC BY-SA image, also reuse the image.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] OSM data, how can we contribute to keep it to a reasonable size?

[Paul Norman]

On 1/17/2018 9:14 PM, Oleksiy Muzalyev wrote:


What can I as a map editor do to keep these data files to a reasonable 
size without compromising  data quality? I mean in the sense, - take 
care of the pennies and the pounds will take care of themselves?


I could think of the following three approaches so far:

- using as short an URL as possible, website=http://somewebsite.com 
instead of website=http://www.somewebsite.com , three characters less; 
[2]


- correct phone number ISO format, phone=+12 345 678 90 12 instead of 
phone=+12 (345) 678 90 12 , two characters less;  [3]


- deleting unnecessary nodes from a way (Shift-Y in JOSM) with 
consequent verification of its geometry;


What else, if anything, could be done? 


Speaking as a developer and frequent consumer of OSM data, don't do any 
of these things to save space.


Instead, worry about ease of editing. If a few meter long way has 
hundreds of nodes, that's a problem for editing, and should be fixed; a 
mass of unnecessary import-sourced tags confuses people, don't use them; 
and overlapping landuse with lots of multipolygons is difficult to edit, 
so should be avoided. Following these behaviors will slightly reduce 
data size, but the point is keeping the map maintainable.


It's also difficult to say what will affect size without a detailed 
understanding of the format and how it's processed. Size is also not the 
only indicator of time to process - for various reasons, relations are 
much slower to work with than ways with most data consumption workflows.


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

Re: [OSM-talk] Adding wikidata tags to the remaining objects with only wikipedia tag

[Paul Norman]

On 10/1/2017 5:39 PM, Yuri Astrakhan wrote:
Lastly, if the coordinates are different, you may not copy it from OSM 
to Wikidata because of the difference in the license.


Just for clarity and anyone reading the archives later, copying from 
Wikidata to OSM is also a problem because Wikidata permits coordinate 
sources like Wikipedia or Google Earth.


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

[OSM-talk] DWG survey on organised editing

[Paul Norman]

The Data Working Group is conducting a survey as part of its work on a
policy covering paid mapping.

When OpenStreetMap started, it was largely a project of hobbyists
contributing to OSM in their spare time. They chose freely what to map
and which tools to use, and they took individual responsibility for
their contributions.

The continuing growth and popularity of OSM have also brought more and
more organised mapping efforts, mostly in the form of companies setting
up paid data teams to improve OSM data in specific regions or for
specific use cases, but also unpaid groups like school classes that are
directed to work on OSM.

These organised mapping efforts are an integral part of today's OSM
contribution landscape and, when done well, help make OSM better and
more widely known.

In order to ensure good communication, and a level playing field,
between individual community members and organised editing groups, the
OSMF Data Working Group has been tasked with developing guidelines for
organised groups. These guidelines will above all set out some
transparency requirements for organised groups - things that are already
voluntarily followed by most groups today, like informing the mapping
community about which accounts edit for the team.

We have prepared the following survey with a few questions about such a
policy to give us a better understanding of what the mapping community
expects from such a policy. The survey is aimed at everyone editing (or
planning to edit) in OSM, whether as individual mappers or as part of a
team, and your answers will help us in fleshing out a draft policy.

Within the scope of the survey, and the policy to be written, we define
paid mapping (or paid editing) as any editing in OSM performed by
someone who is told by a third party what to map (and potentially also
how to map it) and who receives money in exchange. We define other
organised mapping (or editing) as any editing that is also steered by a
third party, but where no money is paid.

The survey is available at https://osm-dwg.limequery.org/741554

--
Paul Norman
For the OSM Data Working Group


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

[OSM-talk] OpenStreetMap Carto release v4.3.0

[Paul Norman]

Dear all,

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

Changes include

- Moving ford and emergency phone to a new tagging scheme
- Moving natural=tree to higher zoom level (z18+)
- Changing embassy color to brown
- Rendering name for waterway=dock
- The same line wrap of amenities for all zoom levels
- Fixing combined railway/highway ordering regression
- Fixing line wrapping bug in Docker
- Some documentation and code cleaning
- Improve ferry line text legibility
- Hide small theme parks and zoos
- Use solid lines for admin borders at low zooms

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

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.2.0...v4.3.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] [Talk-us] Redacting 75, 000 street names contributed by user chdr

[Paul Norman]

On 8/27/2017 10:29 AM, Ian Dees wrote:


I strongly disagree. As a group of people who have received 
extra-judicial powers in the OSM community, they should be expected to 
follow community guidelines to a higher degree than the rest of the 
community.


As the publisher of the OSM database, the OSMF has various legal 
obligations. When we become aware of data that has been illegally copied 
into OSM we need to stop distributing that data, generally by deleting 
it and redacting the old versions so they are no longer accessible. It's 
worth discussing if we can refine the identification of data illegally 
copied data, but we need to remove it in the end, regardless of if we 
want to.


Paul Norman
For the OSMF Data Working Group

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

Re: [OSM-talk] Redacting 75, 000 street names contributed by user chdr

[Paul Norman]

On 8/27/2017 7:26 AM, john whelan wrote:
I would suggest that any street names added by chdr in Canada were 
more than likely derived from CANVEC sources


What makes you believe this to be so?

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

[OSM-talk] OpenStreetMap Carto v3.3.0 release

[Paul Norman]

Dear all,

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

This may not be immediately rolled out to the openstreetmap.org servers,
but that is up to the OSM sysadmin team, not the openstreetmap-carto
maintainers.

Changes include
- Most shops are now rendered as dots z17 to deal with overcrowding
- Font selection is moved to its own file to make customization easier,
  and to make it easier for other styles to reuse our font work
- Rare CJK characters outside the BMP should now render better
- Waterway tunnels in forests and lakes are clearer

This version is unusual because the next version scheduled for release
is v4.0.0, which will have the same cartography as this version.

Thanks to all the contributors for this release.

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

[OSM-talk] OpenStreetMap Carto release v3.2.0

[Paul Norman]

Dear all,

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

Changes include

- Render aeroway terminal buildings like other buildings
- Removed rendering of landuse=farm
- Added rendering for arts centre, fitness centre, plant nursery, mixed
  lift aerialways
- Rendering for fens changed
- Typography for point road-related features, addresses, and water
  features changed
- Removed rendering of waterway=canal as an area
- Take text properties of roads under construction from the type of road
  they will be

Thanks to all the contributors for this release including Richard Fairhurst
and jnachtigall, new contributors.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v3.2.0...v3.1.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] Fixing broken multipolygons

[Paul Norman]

On 2/16/2017 2:51 AM, Yves wrote:
Is there an example where the community has cleaned up the Corine 
multi polygons instead of starting from scratch? 


I've done some Corine cleanup, mainly consisting of deleting obviously 
wrong data. Where I've remapped it's been faster to delete it and start 
from scratch.


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

Re: [OSM-talk] Fixing broken multipolygons

[Paul Norman]

On 2/15/2017 2:51 PM, Sarah Hoffmann wrote:

There is a comparison map where you can see the changes:

https://osmium.osm2pgsql.paulnorman.ca

There are some notable holes, for example in the woods of
Scandinavia. It would be great if they are gone by the time we
switch the software.


Just to note, rendering is currently disabled as I'm reloading the 
database with the latest code and doing some other tests.


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

[OSM-talk] OpenStreetMap Carto database schema change

[Paul Norman]

One of the long-running OpenStreetMap Carto projects has been a database 
schema change, 
https://github.com/gravitystorm/openstreetmap-carto/pull/2533. Included 
in this are


- database schema change;

- disjoint area handling;

- different tag columns; and

- multipolygon handling changes

This is now in a state where the output would benefit from review, not 
just the code, and I have set up a demo at 
https://lua.osm-carto.paulnorman.ca/. Please read the issue and provide 
feedback on Github.


Feedback is especially needed from people who deploy OpenStreetMap 
Carto, as the database schema change requires a database reload. To 
allow people to switch over, cartographic compatibility between the 3.x 
and 4.x series will be maintained for some time. The time has not yet 
been determined.



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

[OSM-talk] OpenStreetMap Carto release v3.1.0

[Paul Norman]

Dear all,

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

Changes include

- Added coffee shop rendering
- Added health clinic rendering
- Adjusted place label typography
- Road shield rendering improvements
- Internal code cleanups

Thanks to all the contributors for this release.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v3.0.1...v3.1.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] Wikipedia/Wikidata admins cleanup

[Paul Norman]

On 1/6/2017 7:37 AM, Mikel Maron wrote:
http://www.openstreetmap.org/changeset/39517002 is an example. There 
were issues with this import, sure. This was not vandalism, 
advertising, or a fatal breakage of the map -- not a situation where 
an immediate action was justified (and definitely there are other 
situations where immediate action is needed). An active mapper and an 
active community were communicating, acting to fix the problems. The 
reverter in this case choose to ignore the mapper and the community 
and took a unilateral action, in contradiction to some guidelines on 
the wiki. This kind of approach discourages community contribution and 
cooperation. We can do a lot better to cooperatively improve the map 
and how we map it.


The revert in this case did not involve the Data Working Group. The DWG 
statement on this issue is 
https://lists.openstreetmap.org/pipermail/talk-ca/2016-September/007260.html. 
Quoting from it



Advance permission is not required for reverts, nor for normal mapping
activities. At the same time, users are expected to be responsible,
particularly when using tools for reverting which allow large-scale
changes where other users may disagree with them.

Where there are problems with an import reverting is an option, but
just one of many, and often not the appropriate first action. Unless
there are legal problems or fatal problems with the import it is
preferable if the original importer can fix the problems in a timely
manner. There was every indication this was going to happen in this case.

The revert of 39517002 was inappropriate and counter-productive. New
actions like this revert may lead to further Data Working Group
involvement and potentially blocks. If the Canadian community needs help
reverting 41749133 and 41756737, the Data Working Group can revert those
changesets.


Because there seems to be some confusion, neither Nakaner or Mikel are 
members of the Data Working Group.


Frederik Ramm, Andy Townsend, and myself are the three people in this 
thread who are also members of the DWG. Unless they state otherwise, 
their opinions aren't representing the DWG.


Paul Norman
For the Data Working Group
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Square (Place, Platz,Piazza, Plaza, …)

[Paul Norman]

On 1/2/2017 4:31 AM, Daniel Koć wrote:
If you mean default style (osm-carto), it's already appointed for 
rendering =} :


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


It's wrong to say it's "appointed" for rendering. There's an issue open 
requesting it be rendered, but that doesn't mean we have decided to 
render it, and if we do want to render it, it doesn't mean we can find a 
way to do so.


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

[OSM-talk] OpenStreetMap Carto release v2.44.1

[Paul Norman]

Dear all,

Today, v2.44.1 of the openstreetmap-carto stylesheet (the default
stylesheet on openstreetmap.org) has been released. Also, v2.44.0 was
released last month without an email, so this email includes changes
in both.

v2.44.0 has been rolled out to the openstreetmap.org servers, but v2.44.1
has not yet.

Major changes are
- Rendering of restricted access roads and paths significantly changed
- Changed to use Noto fonts for all languages

Other changes in both versions include
- A code of conduct adopted, based on the Go code of conduct
- Adjustments to city wall rendering
- Revised low zoom place rendering
- Render both house name and number if address has both

Thanks to all the contributors for this release, in particular Lukas
Sommer, Hsiao-Ting Yu and vholten for work in debugging complex font
issues with the Noto CJK fonts.

For a full list of commits from both releases, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v2.43.0...v2.44.1

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] Map features page on wiki

[Paul Norman]

On 2016-10-01 02:36 PM, Tobias Knerr wrote:

Maybe I'm a bit late to the party, but I don't feel it's great to give 
special treatment to Mapnik in the infobox, and there is not enough 
room for presenting all the renderers there. 


OpenStreetMap Carto is given special treatment on osm.org by being the 
default layer, so the wiki should reflect that.


Just a reminder: All the layers on openstreetmap.org use Mapnik, a 
rendering library. There is no one "Mapnik" layer.


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

Re: [OSM-talk] Multilingual feedback wanted for OpenStreetMap Carto

[Paul Norman]

On 9/17/2016 7:32 PM, Paul Norman wrote:
I'm looking for feedback from people who read non-latin languages on a 
proposed OpenStreetMap Carto font change.


We are considering moving to Noto fonts and could use feedback from 
people who can read languages which have non-latin scripts, 
particularly Asian languages. I've made previews in about a dozen 
different languages at 
https://github.com/gravitystorm/openstreetmap-carto/pull/2349#issuecomment-247819822 
and want to check that there are no new problems. We may have to 
adjust font sizes, but that's a different issue.


If you've got feedback, please leave it on 
https://github.com/gravitystorm/openstreetmap-carto/pull/2349


We decided to merge the changes. Thanks to everyone who supplied 
feedback on GitHub. There won't be any change on the map you see on 
OpenStreetMap.org until we release a new version and operations deploys it.


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

Re: [OSM-talk] Multilingual feedback wanted for OpenStreetMap Carto

[Paul Norman]

On 9/19/2016 3:24 AM, Andy Townsend wrote:

On 19/09/2016 11:13, Paul Norman wrote:


The changes this topic is about are not live on openstreetmap.org. 
The original message has details, but the issue tracking the proposed 
changes is 
https://github.com/gravitystorm/openstreetmap-carto/pull/2349, and 
you can see images there that show what the change is.


So perhaps the "huge improvement for the situation in Korea" mentioned 
above is due to the move to Mapnik 3 (which as I understand it has 
happened) rather than a font change?


While I can't speak for someone else, there are significant changes to 
the appearance of Korean text in the PR and a lot of images showing 
Korean that fix a few known issues. Also, Mapnik 3 didn't do too much 
for Korean.


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

Re: [OSM-talk] Multilingual feedback wanted for OpenStreetMap Carto

[Paul Norman]

On 9/19/2016 2:32 AM, Oleksiy Muzalyev wrote:


The hyphens are not disappearing from the Ukrainian geographical 
names. The names are just always spit in two lines at a hyphen for 
some towns. Exactly as for Wotton-under-Edge 
 in the UK. Google 
map shows the name /Wotton-under-Edge/ always in one line on the map: 
https://www.google.com/maps/@51.6338253,-2.3526667,14.95z?hl=en , but 
the OSM map always shows this name split in two lines.


In France too some towns' names are always rendered in two lines now. 
For example: Saint-Jean-d'Angély 
 : 
http://osm.org/go/equZGaGg-- . Maybe it is an indented feature now, 
however at Google and Bing maps such town names are displayed in on 
line, as it should be.




The changes this topic is about are not live on openstreetmap.org. The 
original message has details, but the issue tracking the proposed 
changes is 
https://github.com/gravitystorm/openstreetmap-carto/pull/2349, and you 
can see images there that show what the change is.


The OpenStreetMap Carto project uses GitHub for issue tracking, so 
unless comments are made on the pull request they are likely to lost and 
not be considered when deciding to accept proposed changes.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Multilingual feedback wanted for OpenStreetMap Carto

[Paul Norman]

I'm looking for feedback from people who read non-latin languages on a 
proposed OpenStreetMap Carto font change.


We are considering moving to Noto fonts and could use feedback from 
people who can read languages which have non-latin scripts, particularly 
Asian languages. I've made previews in about a dozen different languages 
at 
https://github.com/gravitystorm/openstreetmap-carto/pull/2349#issuecomment-247819822 
and want to check that there are no new problems. We may have to adjust 
font sizes, but that's a different issue.


If you've got feedback, please leave it on 
https://github.com/gravitystorm/openstreetmap-carto/pull/2349



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

Re: [OSM-talk] Overpass XAPI URL Status

[Paul Norman]

On 9/14/2016 11:04 AM, mmd wrote:

Am 14.09.2016 um 09:30 schrieb Bryce Nesbitt:

>I help support a large company that uses OSM data, pulled via a specific
>query at  ://www.overpass-api.de/api/xapi
>. This query runs about once a month.

xapi endpoint is the only service that is blocked right now. That's due
to one particular mobile app firing off excessive amounts of queries.
Details are also known to the OSMF board.


There's been questions about this and I want to clarify that

- Overpass runs on FOSSGIS Germany hardware, not OSMF hardware

- The OSMF board is not involved and has not been sent any details, nor 
do we need to be involved


Even if it were on OSMF hardware, scrapers and badly behaving apps are 
an sysadmin/ops issue and not one the board would normally need to get 
involved with.


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

[OSM-talk] OpenStreetMap Carto release v2.43.0

[Paul Norman]

Dear all,

Today, v2.43.0 of the openstreetmap-carto stylesheet (the default
stylesheet on openstreetmap.org) has been released. It has not yet
been rolled out to the openstreetmap.org servers.

Changes include

- Adjust alotments pattern
- Whitespace cleanups of code
- Adjust colours of dog parks and construction sites
- Increase font size of addresses
- Fix combination of long names and oneway arrows

Thanks to all the contributors for this release, including Ircama and 
measad, both new contributors.


For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v2.42.0...v2.43.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] OpenStreetMap Carto release v2.42.0

[Paul Norman]

On 8/24/2016 5:25 AM, Dave F wrote:

Hi

Has label positioning with irregular polygons been improved? If so, it 
works very well:

https://www.openstreetmap.org/#map=16/51.3166/-2.1700


I don't think we've made any changes there. It could be something else 
that has changed in the data. We actually don't have anything to do with 
label positioning algorithms beyond a couple basic options, the details 
are handled by Mapnik.


Is there a list of your emails regarding changes. As an end user I 
don't find the 'full list of commits' particularly easy to understand.


If you're talking about past releases, there is no list of emails. We've 
had https://github.com/gravitystorm/openstreetmap-carto/issues/1430 open 
for generating a changelog but haven't decided what action to take.


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

[OSM-talk] OpenStreetMap Carto issues of interest

[Paul Norman]

There are some OpenStreetMap Carto issues which might be interesting to 
a larger audience


Improving the water colour: 
https://github.com/gravitystorm/openstreetmap-carto/issues/1781


There's been a discussion of options for improving the water colour to 
improve contrast with a number of other features.


Change access rendering: 
https://github.com/gravitystorm/openstreetmap-carto/pull/2257


This needs more people to try the PR in their local area. Access 
representations is a *hard* problem to solve and we're not going to get 
it perfect or satisfy everyone, but hopefully we can do something a lot 
better


Plan database re-import (aka hstore and lua): 
https://github.com/gravitystorm/openstreetmap-carto/issues/1504


This is one of the big long-term planning issues for the database 
reload, changing the schema, and enabling osm2pgsql --hstore. It needs 
more people testing. You can see additional issues: 
https://github.com/gravitystorm/openstreetmap-carto/issues?q=is%3Aopen+is%3Aissue+label%3Alua


Review onboarding: 
https://github.com/gravitystorm/openstreetmap-carto/issues/2291


If you're reading this on the lists and aren't following the issues 
already, the onboarding experience is relevant to you if you want to get 
involved. It's hard for the maintainers to evaluate; we've all been 
working at map styles for some time.


Comments are best posted on the GitHub issues, otherwise they'll 
probably get lost when reviewing the discussion.


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

[OSM-talk] DWG looking for Chinese translation help

[Paul Norman]

The OSM Foundation Data Working Group is looking for help with 
translating a couple of messages to Chinese. These messages are about 
data we're going to need to redact, so we want to make sure they understand.


If you can help, please contact d...@osmfoundation.org


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

[OSM-talk] OpenStreetMap Carto release v2.41.0

[Paul Norman]

Dear all,

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

Changes include
* More consistent fonts for POI labels
* Less saturated stadiums
* Rendering obelisks and dog parks
* An updated list of font packages
* Cleaning up the font list
* Rewriting the road colours script for easier changes
* Various bug fixes

Thanks to all the contributors, including jdhoek, a new contributor.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v2.40.0...v2.41.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] Opportunity for a new featured layer on osm.org (was: Direct Access to MapQuest map tiles ending)

[Paul Norman]

With the MQ Open changes, there is an opportunity for a general-purpose 
map style to become a new featured layer on osm.org. The requirements 
for a new layer are at 
http://wiki.openstreetmap.org/wiki/Featured_tile_layers/Guidelines_for_new_tile_layers


The key ones are
- Supported by whomever is hosting the layer
- Global coverage
- Technically capable
- Up to date data

If someone running a set of tiles wants help proposing them to the OWG, 
I'd be able to do so. I did something similar for the HOT style. Let me 
know off list if you're interested.


On 6/15/2016 9:43 AM, Jeff Medaugh wrote:


MapQuest is moving to a 100% cloud solution - the new infrastructure 
dictates that all tile access will require a key. Details on how to 
get keys, SDKs and general migration information is below:



On Monday, July 11, 2016, our direct tile access to MapQuest legacy 
maps will be discontinued. After Monday, July 11, 2016, we’ll require 
those using our direct tiles access to sign up for a plan on the 
Developer Network and transition to one of our four mapping solutions:


 *

MapQuest plugin for Leaflet

 *

iOS mobile SDK

 *

Android mobile SDK

 *

Static map API

Get new keys and SDKs here: https://developer.mapquest.com/

FAQ and details are below. If you have additional questions about 
these changes, please email us at developer-servi...@mapquest.com 
or contact us via our forum 
(URL below).


*FAQ:*


If I don’t sign up for a new AppKey, will my service be shut off?

If you’re currently getting direct tile access, your service will be 
shut off beginning Monday,  July 11, 2016. We encourage you to sign up 
for a plan to access an AppKey and access our various mapping solutions.



What are the differences between the plans you offer?

The available plans include: Free, Basic, Plus, Business, Business 
Enhanced, Business Plus, and Business Plus Enhanced. Please see our 
plans page for pricing and additional information. We also offer an 
Enterprise-level plan that includes additional benefits and 
flexibility. If you are interested in an Enterprise-level plan, please 
contact us to discuss licensing options.



How are transactions counted within your mapping solutions?

A map transaction is generally generated under the following 
circumstances:


 *

The initial load of the map when using SDKs such as the JavaScript
Maps API, Leaflet Plugins, Mobile SDKS, or legacy Flash Maps API

 *

There is a change in zoom level

 *

There is a change in map type, for instance, a change from the
default map to satellite imagery

 *

The user pans and causes more than 40% of the displayed map to
change (legacy Flash Maps API only).

 *

A request is made to the Static Map API Web Service.


What if I need help with the transition to a new mapping solution?

Please visit the forums on our Developer Network if you have questions 
about transitioning from direct tile access to Leaflet, Mobile SDK or 
Static Map API.


https://developer.mapquest.com/forum

--

*Jeff Medaugh *Product Manager - Developer Services

MapQuest 




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


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

Re: [OSM-talk] Announcement: Direct Access to MapQuest map tiles without a key will end on 11 July 2016. Details on getting keys and SDKs

[Paul Norman]

- Does this mean that MQ Open tiles will need to be removed from osm.org?

- MQ Open tiles on open.mapquest.com are still pointing at an old style. 
Will this be changing?


- Will MQ be updating the various references they've added on the OSM 
wiki which contain information on how to use MQ Open tiles?



On 6/15/2016 9:43 AM, Jeff Medaugh wrote:


MapQuest is moving to a 100% cloud solution - the new infrastructure 
dictates that all tile access will require a key. Details on how to 
get keys, SDKs and general migration information is below:



On Monday, July 11, 2016, our direct tile access to MapQuest legacy 
maps will be discontinued. After Monday, July 11, 2016, we’ll require 
those using our direct tiles access to sign up for a plan on the 
Developer Network and transition to one of our four mapping solutions:


 *

MapQuest plugin for Leaflet

 *

iOS mobile SDK

 *

Android mobile SDK

 *

Static map API

Get new keys and SDKs here: https://developer.mapquest.com/

FAQ and details are below. If you have additional questions about 
these changes, please email us at developer-servi...@mapquest.com 
or contact us via our forum 
(URL below).


*FAQ:*


If I don’t sign up for a new AppKey, will my service be shut off?

If you’re currently getting direct tile access, your service will be 
shut off beginning Monday,  July 11, 2016. We encourage you to sign up 
for a plan to access an AppKey and access our various mapping solutions.



What are the differences between the plans you offer?

The available plans include: Free, Basic, Plus, Business, Business 
Enhanced, Business Plus, and Business Plus Enhanced. Please see our 
plans page for pricing and additional information. We also offer an 
Enterprise-level plan that includes additional benefits and 
flexibility. If you are interested in an Enterprise-level plan, please 
contact us to discuss licensing options.



How are transactions counted within your mapping solutions?

A map transaction is generally generated under the following 
circumstances:


 *

The initial load of the map when using SDKs such as the JavaScript
Maps API, Leaflet Plugins, Mobile SDKS, or legacy Flash Maps API

 *

There is a change in zoom level

 *

There is a change in map type, for instance, a change from the
default map to satellite imagery

 *

The user pans and causes more than 40% of the displayed map to
change (legacy Flash Maps API only).

 *

A request is made to the Static Map API Web Service.


What if I need help with the transition to a new mapping solution?

Please visit the forums on our Developer Network if you have questions 
about transitioning from direct tile access to Leaflet, Mobile SDK or 
Static Map API.


https://developer.mapquest.com/forum

--

*Jeff Medaugh *Product Manager - Developer Services

MapQuest 




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


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

Re: [OSM-talk] [Talk-us] Reporting Attribution Issues on Mapbox maps

[Paul Norman]

On 6/10/2016 3:03 PM, Serge Wroclawski wrote:
But I'm a little concerned about non-MB hosted maps. If not this URL, 
where can we report  attribution issues related to non-hosted Mapbox 
maps and  can you link to that other place we can report attribution 
issues related to that other kind of customer from the same web page?


Webpages not hosted by Mapbox that are using Mapbox tiles with 
OSM-derived data would be responsible for their own attribution, so 
you'd need to contact them like with any other site. If someone isn't 
comfortable doing this or not having success, they can forward the 
information to le...@osmfoundation.org and the LWG can look into the issue.


Also, if someone wants to contact Mapbox about an issue on mapbox.com 
and doesn't want to use the webform, they could use one of the contact 
methods for their designated agent for notifications of claimed 
infringement at http://www.copyright.gov/onlinesp/agents/m/map-box.pdf.


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

Re: [OSM-talk] RfD notification: Purge tag "priority" from tracks

[Paul Norman]

On 4/8/2016 7:14 AM, Roland Olbricht wrote:


This constitutes a mechanical edit. Therefore, I would like to notify 
you that I have put a request for discussion on talk-transit@ .
If you would like to discuss, please do so there. 


The talk-transit@ list is inactive, and not entirely relevant since 
railways are not just transit. Because you're only looking at items in 
the UK and Germany you're best off consulting with the local lists for 
those places.


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

[OSM-talk] Switch2OSM graphic design help needed

[Paul Norman]

Switch2OSM is undergoing a rewrite to allow a different contribution 
model. As part of this we had to switch from the existing WordPress 
design to one using Jekyll. This requires a new visual design, and we're 
looking for help from a graphic designer.


This is independent of content changes, so you don't need to know 
anything about the subjects the guides cover.


There's some more information at 
https://github.com/switch2osm/switch2osm.github.io/issues/3, and the 
content can be seen at http://switch2osm.github.io/ with just a default 
Jekyll style.


If you're interested in helping, please get in touch. A company could 
also help by letting one of their graphic designers work on it.


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

[OSM-talk] Redaction of some Afghanistan data

[Paul Norman]

The Data Working Group recently had to perform a large redaction in
Afghanistan of data from two mappers who had used Google. A redaction is
where an object is removed from the current data and previous versions
are hidden in the API. They are done to hide data that cannot be shown
for copyright or other legal reasons.

There is no active local mailing list, so I'm letting talk@ know
instead. If you are in touch with local mappers, you can forward this to
them. It looks like most of the data that had to be removed was new
data, which will have been removed cleanly without needing any
additional cleanup.

If you have concerns about the source that was used for mapping
something, please contact the Data Working Group at
d...@osmfoundation.org with information, including links to changesets.
It helps if you also start a changeset discussion on one of the
changesets nicely asking the mapper for more information about what they
did.

It is much better to catch this type of problem early, simplifying and
reducing the cleanup work required.

Paul Norman

For the Data Working Group


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

Re: [OSM-talk] Tagging Piers vs Docks

[Paul Norman]

On 2016-03-11 9:50 AM, Janko Mihelić wrote:

Does iD have an American english translation? Maybe it should.
iD is in en_US, with an en_GB translation. For example, the untranslated 
help text mentions freeways, while en_GB mentions motorways.


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

[OSM-talk] osm2pgsql 0.90.0 release

[Paul Norman]

Osm2pgsql 0.90.0 has been released. The major changes since 0.88.0 are

- Windows support is much improved, and osm2pgsql builds natively with MSVC

- Osm2pgsql now requires a C++11 compiler

- Memory overhead for very small extracts is significantly reduced

- Multi-threading support is enabled for Windows

- The build system has switched from autotools to cmake

- Parsing is now done by libosmium and protobuf-c-compiler is not required

- Multi-backend improvements and bug fixes

- PBF support is no longer optional

- Legacy code from 32-bit node IDs has been removed

- Builds now generate no GCC or Clang warnings or errors

Upgrading is strongly recommended for anyone using the multi backend or 
Windows.


This will be the last version that supports PostGIS 1.5 or PostgreSQL 
9.0. Both of these have been end of life for some time.


Future version will also use EPSG 3857 by default, not 900913.

A full list of commits can be found at 
https://github.com/openstreetmap/osm2pgsql/compare/0.88.0...0.90.0
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Applicability of wiki tagging and votes: may, should or must

[Paul Norman]

On 1/29/2016 8:49 AM, Matthijs Melissen wrote:

On 29 January 2016 at 17:37, Mateusz Konieczny  wrote:

"but that's not much to do with tagging diversity" - I would dispute
it, from my personal experience. Tagging diversity IS one of real
problems in using OSM data.

+1.


I'm going to disagree, even though I understand exactly why both Mateusz 
and Matthijs come to this conclusion. As an OpenStreetMap Carto 
maintainer, tag fragmentation is a pain. For most data consumers? It 
doesn't matter. Most of the time they're using a small number of well 
established tags, and if they run into an edge case where there's tag 
fragmentation they're not going put in a great deal of time.


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

Re: [OSM-talk] Fixing Starbucks Wikipedia Tags (Was Nominatim Weakness)

[Paul Norman]

On 1/21/2016 1:44 PM, Clifford Snow wrote:

When we are done cleaning up Starbucks, we'll still have at least one 
Starbucks with a wikipedia link, the original store 


But this won't be a link to the Starbucks article, but instead the 
specific one on that notable store.


I still believe that Nominatim should give back results based on bbox 
regardless of wikipedia for certain features. In this case, amenity=cafe.


If you want results only within a bounding box, set that parameter when 
querying Nominatim. See 
http://wiki.openstreetmap.org/wiki/Nominatim#Parameters for 
documentation on Nominatim, or as an example,


- 
http://nominatim.openstreetmap.org/search?format=xml&bounded=1&viewbox=-123.1%2C50.2%2C-122.7%2C50.1&q=Starbucks 
for a query with few results and
- 
http://nominatim.openstreetmap.org/search?format=xml&bounded=1&viewbox=-123.1%2C55.2%2C-122.7%2C55.1&q=Starbucks 
for a query with no results.


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

Re: [OSM-talk] Involving Cyclists in OSM

[Paul Norman]

On 12/8/2015 7:39 PM, Clifford Snow wrote:


On Tue, Dec 8, 2015 at 6:56 PM, Paul Norman <mailto:penor...@mac.com>> wrote:


For what points to pitch, I'd suggest

- Crowd-sourced, so they can edit themselves, meaning they can get
fixed data in minutes to days, not quarters to years


This is my goal. More mappers. They can use other sources, but OSM is 
really the only one that they can actually improve.



- Useful for cycling advocacy, as it presents a more accurate less
car-focused set of data, and the open tools around OSM make it
easier to draw potential options


Can you help me understand this better? Maybe an example.


If you're trying to advocate for a cycle route you can do more useful 
stuff with OSM than with other tools, such as examine average travel 
times for improved cycle connection. OpenTripPlanner can be used for 
this. You can do stuff more sophisticated than using photoshop to draw 
in a line. People in the UK are using OSM in public right of way 
advocacy because you can add details like buildings, other paths, parks, 
and other features which make a proposal make more sense and generally 
be more attractive.



- Areas like the North Shore in Vancouver have mountain paths
which aren't in and will never be in "official" datasets, but are
essential if you're cycling there. I'm not sure if there's
analogous areas in the Seattle area.


Got a link to the area? Be fun to show.


http://www.openstreetmap.org/#map=17/49.332/-122.984&layers=C

As the paths are named by north shore bikers, they are not family safe.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Involving Cyclists in OSM

[Paul Norman]

On 12/8/2015 4:40 PM, Clifford Snow wrote:
I am meeting with one of the key players in Seattle's cycling clubs to 
pitch doing a presentation to their membership. I'm interested in 
hearing from cyclists on why and how OSM is useful to them. I have no 
problem talking about the open data concept and incorporating slippy 
maps, but I want to make sure I cover the salient points that would 
interest cyclists. If you know of any websites that use bike routes or 
otherwise make use of OSM data that would really be great.




Cycling is an area where OSM is at its strongest, given the traditional 
focus on car navigation by other data sources. I've used the other data 
sources professionally, and they're improving, but not near OSM's 
completeness or detailed attributes.


Some bigger projects

http://www.cyclestreets.net/ (UK-only) has cycle-specific route planning

http://cycle.travel/ has similar features, and includes US coverage. It 
does a reasonable job of dealing with bad TIGER data in the rural US. 
This is probably less of an issue in Seattle since you'd be looking at 
more urban or mountain biking, not rural "roads".


http://www.opencyclemap.org/ is also worth a demo, being one of the most 
established bicycle-focused renderings


OpenTripPlanner can use OSM data and do multi-modal routing, which can 
be essential for data-based cycling advocacy


osm.org itself has bicycle routing from two engines

OSM maps on Garmin devices including cycle devices is a typical OSM 
strength. Depending on audience, they might be interested specifically 
in this.


For what points to pitch, I'd suggest

- A more complete data source for bicycles, walking, and anything other 
than car navigation


- Crowd-sourced, so they can edit themselves, meaning they can get fixed 
data in minutes to days, not quarters to years


- Useful for cycling advocacy, as it presents a more accurate less 
car-focused set of data, and the open tools around OSM make it easier to 
draw potential options


- I'd avoid "open data" as in the US that's often taken to mean working 
with government data.


- Areas like the North Shore in Vancouver have mountain paths which 
aren't in and will never be in "official" datasets, but are essential if 
you're cycling there. I'm not sure if there's analogous areas in the 
Seattle area.


What area does the club focus on? (e.g. mountain biking, commuter 
cycling, etc)


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

Re: [OSM-talk] From osmf-talk: "Balancing the presence of the Humanitarian OpenStreetMap Team (HOT US Inc) in the OpenStreetMap Foundation"

[Paul Norman]

On 12/2/2015 2:12 PM, Jean-Guilhem Cailton wrote:
It also happens that I have stopped renewing my membership to the OSMF 
after an election where a candidate was excluded from the vote because 
his views on a controversial subject (related to license change) were 
strongly different from those of the majority of the previous Board. 
Note that Mr. Maron was already a member of this outgoing Board, that 
had a conception of basic democracy different from mine, according to 
which it should have been up to the voters not to vote for a candidate 
if they didn't agree with his views. So, anyway, I cannot write to 
that list.


Although I wasn't on the board at the time, I was around then, and the 
situation was a bit different.


In 2012 two people tried to run for board without being members (i.e. 
they couldn't), and then someone tried to pay or register for their 
membership on their behalf. The board at the time rejected their 
application.


I can't find any minutes from the time and can't speak to the views of 
the board at the time, but there was a view that the person attempting 
to pay was doing it solely to cause problems.


The board at the time was Steve Coast, Henk, Oliver, Mikel, Matt Amos, 
Dermot, and Richard Fairhurst.


I didn't know the background on one of the individuals, but I'd have 
rather seen the other become a member the normal way (paying 
themselves), run for board, and lose.


Under the AoA the board cannot stop a member from running in a board 
election, and a member can only be removed for a small number of 
reasons, and they have a right of appeal to the next general meeting. 
There are also provisions under the Companies' Act for OSMF members to 
remove board members.


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

Re: [OSM-talk] What3words

[Paul Norman]

On 11/22/2015 2:39 AM, Colin Smale wrote:


I have heard a few times recently about what3words, a new novel 
coordinate/addressing system for the whole world.


Could/should we be doing anything to support/facilitate/implement this 
system in OSM?




No. Other people might talk about the numerous problems how what3words 
doesn't do what it claims to accomplish or flaws in the technical 
implementation, but there's a much simpler reason why it doesn't belong 
on osm.org: It's a closed proprietary system that others can't reuse.


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

[OSM-talk] Fw: new message

[Paul Norman]

Hello!

 

New message, please read <http://immugen.com/ways.php?j>

 

Paul Norman

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

Re: [OSM-talk] Activity statistics per city (or region)

[Paul Norman]

On 10/26/2015 2:52 AM, César Martínez Izquierdo wrote:

On 26 October 2015 at 10:28, Mateusz Konieczny  wrote:

>"provides access to existing users" - I am not sure what you want. Who
>was last to edit given element? List of all user accounts? List of users
>active in a given region? Something else?

I mean for instance list of all users and its declared location
(assuming that this is a poor indicator: we tend to sometimes edit in
remote places, declared location may be outdated, etc).


This information is not published. In my experience, it's also not very 
useful, with few users declaring their location, and their location not 
necessarily corresponding to where they spend time locally.


Pascal Neis' previously mentioned site, http://resultmaps.neis-one.org/, 
is probably a good place to start. You'll want to read his blog posts 
and any of his studies that are referenced in them.


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

Re: [OSM-talk] Activity statistics per city (or region)

[Paul Norman]

On 10/26/2015 8:24 AM, Fabian Schmidt wrote:
It is rare but there are users who renamed their account, so there are 
more user names than numeric user ids. 


No. Although users have renamed their account, this doesn't increase the 
number of user names, it changes one of them.


Additionally, user IDs are a PostgreSQL serial so there can be gaps, and 
spam users are sometimes completely deleted.


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

Re: [OSM-talk] open question about boundaries sharing nodes with ways or nodes

[Paul Norman]

On 10/14/2015 1:23 AM, Frederik Ramm wrote:

You'd have to research how the boundary is defined. If there is some
sort of legal definition that goes "the boundary has the following
geometry: from lat/lon A to lat/lon B to lat/lon C...", independent of
the river or highway, then it makes sense to have two different
geometries. But if the legal definition goes "the municipality of X
extends until the middle of the river Y" then it would be wrong to have
two different geometries in OSM.


There's another possibility, found more commonly in remote areas, and 
not often in Europe: none of the above.


Boundaries are not always rigorously defined, and it may not be set if 
the boundary precisely follows the river or not, or in the case of 
multiple similar branches, which branch is followed.


There's also the case where the boundary is defined to be the river, but 
not follow when the river shifts, or only follow some types of river shifts.


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

Re: [OSM-talk] Somebody should offer planet file postgis dump files

[Paul Norman]

On 9/27/2015 6:55 AM, Daniel Koć wrote:
Even if this is not 6 days long, it may still make sense to use 
differential dumps for example.


I don't know how much additional resources we would need to create 
them and how faster would it be to import the data, but after one big 
import at - let's say - the beginning of a month (full copy) you just 
update it with small "patches" (daily diffs) and you're done for some 
time. Weekly diffs may be also of some use, but it needs some testing 
to know, of course.


If this would cause disc space shortage, we could drop creating full 
dumps weekly and make them only once a month.


This could make importing much easier for established services at the 
cost of more trouble to start the new ones (they should probably wait 
for next month to be in sync if we need to drop full weekly dumps), 
but I think it's worth considering. 


planet.osm.org has been providing weekly dumps and daily, hourly, and 
minutely diffs of data for a few years.


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

Re: [OSM-talk] Somebody should offer planet file postgis dump files

[Paul Norman]

On 9/26/2015 5:54 PM, Stephen Knox wrote:
Does it really take this long to import a planet file these days? I 
would be interested to know if anyone else has imported one recently. 
I may import one myself at some point, but if it takes 6 days I 
probably won't bother.


For osm2pgsql, it depends if you're planning on doing updates or 
updating by reimporting. On my fairly powerful dev box, it took about 24 
hours for a database capable of updating. On a server with 
specifications designed for dealing with full planet rendering, it took 
about 6 hours for a database not capable of updating (--slim --drop).


http://paulnorman.ca/blog/2014/11/zfs-settings-for-osm2pgsql/ is 
comparing another setting, but does include details about the time taken.


The command line I used most recently is something very close to what 
osm2pgsql suggests, osm2pgsql --slim --drop --cache 24000 --flat-nodes 
nodes.bin --number-processes 8 planet-latest.osm.pbf.


Osmosis pgsnapshot is a bit different. If you don't need way geometries 
built, it is exceptionally fast. If you do, you need to use a tempfile 
unless you have 64GB of RAM. I don't have recent experience, since my 
last pgsnapshot imports were on VMs which had IO performance like most 
VMs - poor.


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

Re: [OSM-talk] The Proposed Great Colour Shift

[Paul Norman]

On 8/22/2015 4:20 AM, Daniel Koć wrote:
Could anybody with technical background in the inner OSM workings tell 
us what is holding us back with introducing new styles (be it raster 
styles, additional/interactive layers or even vector tiles)?


Only a lack of people willing to do the work.

Multiple people have started their own styles based on OpenStreetMap 
Carto. Both the French style and the new German style started this way. 
I believe both the cycle map and transport map on osm.org are using 
vector tile infrastructure now. OpenSeaMap provides a rendered overlay.


If you're asking about on osm.org, I believe there's just been a lack of 
interest. To be added a layer would need to support the criteria on 
http://wiki.openstreetmap.org/wiki/Strategic_working_group/New_Tile_Layer_Guidelines. 
I believe the last request was the HOT layer, which got added.


If another tile host wanted to write a proposal to add their tiles, I'd 
be willing to talk to them about helping. I still have all the HOT 
stuff, so wouldn't need to redo that.


For new layers which are overlays or in-client vector tile rendered, 
there would also probably be a pull request needed to add the necessary 
code.


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

Re: [OSM-talk] The Proposed Great Colour Shift

[Paul Norman]

On 8/20/2015 9:32 AM, john whelan wrote:
As someone affected I wish to dissent therefore you do not have 
consensus not every one consents.


Although not essential to the style discussion, I think it's important 
to correct this point. Consensus is not unanimity. 
https://tools.ietf.org/html/rfc2418#section-3.3 is a good read, as it 
mentions mailing lists. Another part is identifying and resolving of 
concerns. This does not mean everyone will agree with how their concern 
is resolved, which is impossible when two concerns do not have a 
compatible resolution.


The decision to merge or not lies with the maintainers, and ultimately, 
with Andy. We'll look at comments on the Github issue, the cartography 
change and come to a final decision.


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

[OSM-talk] Preview of OpenStreetMap Carto proposed road rendering changes

[Paul Norman]

I have set up a preview at 
http://bl.ocks.org/pnorman/raw/c61d6b11193081910866 of the proposed road 
rendering changes done by Matkoniecz as part of GSOC. There are more 
details at 
https://github.com/gravitystorm/openstreetmap-carto/pull/1736#issuecomment-131638433, 
but please keep in mind that only selected parts of the world are loaded 
into my database, and it is not as fast as the OSMF production hardware.


I've tried to pick a reasonable cross-section of areas, but if there's a 
specific area you want to see you can always load it locally in 
Kosmtik/Tilemill.


Issues should go to 
https://github.com/gravitystorm/openstreetmap-carto/pull/1736, not here.


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

Re: [OSM-talk] Best base to build on ...

[Paul Norman]

On 8/15/2015 2:09 PM, Lester Caine wrote:

The simple answer seems to be that there is no standard when it comes to
mapping applications and everybody creates their own personal special
such as kosmtik rather than working with established standards:(
Kosmtik is a standard. But it's a development tool for stylesheet 
design. The other options are Mapbox Studio and Tilemil. All three are 
essentially desktop applications, although the developer using them 
might interact with them via a browser.


The former doesn't support a raster tile style, has tie-ins with Mapbox 
that make it difficult to use independently, and does not work 
reasonably with styles in version control. The problem with Tilemill is 
that is is abandoned, and includes in-program text editing, which adds 
significant complexity to the codebase, and this text editing does not 
function with large complex styles.


It's also not a question of duplication, as all of these options are 
written in nodejs and the map rendering parts share common modules.


renderd, and all similar software, serves a completely different 
purpose, and are not good options for applications where Kosmtik, 
Tilemill, and Mapbox Studio make sense.


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

Re: [OSM-talk] OpenStreetMap Carto v2.33.0 release

[Paul Norman]

On 8/15/2015 1:15 PM, Ruben Maes wrote:

17 117 occurences is not 'not in the database'.
No, a key not in 
https://github.com/gravitystorm/openstreetmap-carto/blob/master/openstreetmap-carto.style 
is not in the database. landcover is not in that list, so is not in the 
database.


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

Re: [OSM-talk] OpenStreetMap Carto v2.33.0 release

[Paul Norman]

On 8/15/2015 4:26 AM, Dave F. wrote:

Hi

Does the combined wood/forest update include landcover=trees? If not 
it needs to be included all three should render the same (IMO).


No. Nor are there any issues created about rendering landcover=trees. As 
the landcover key is currently not in the database, it is not happening 
in the short-term either.


For clarity, this is not to imply that we will or will not render 
landcover=trees. As there's no issue about it, it hasn't been discussed.


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

Re: [OSM-talk] Best base to build on ...

[Paul Norman]

On 8/15/2015 8:14 AM, Lester Caine wrote:

Not getting much help on the GB list so I thought I'd widen the
question. A couple of years back I had my own server setup working with
a base of OSRM and routing covering the UK. While the map server is
still working, routing has packed up and some of the alternate base maps
are no longer accessible.

...

The obvious question is that given tilemill is not longer being
maintained, what are the preferred alternatives?
Kosmtik is the preferred alternative to Tilemill, but both of these are 
style design programs, not programs for serving tiles to others. I have 
no doubt that you could proxy them via a caching proxy, but this is a 
horrible idea.


Use any one of the standard tile rendering servers like renderd+mod_tile 
or tirex+mod_tile. If you don't need update support (which you don't if 
you were considering Tilemill) then mapproxy, tilestash, tilecache, and 
non-OSM specific options are available.


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

Re: [OSM-talk] OpenStreetMap Carto v2.33.0 release

[Paul Norman]

On 8/15/2015 4:45 AM, tony wroblewski wrote:

The woodland change looks much better, but would it not be possible to
render broadleaved, needleleaved and mixed using different tree
images, as seen on other maps?
Not at the moment. See 
https://github.com/gravitystorm/openstreetmap-carto/issues/822


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

Re: [OSM-talk] landcover=trees

[Paul Norman]

On 8/15/2015 8:13 AM, Daniel Koć wrote:

I asked about it here:

https://github.com/gravitystorm/openstreetmap-carto/issues/1724#issuecomment-128702817 



but the issue is closed now without too detailed discussion


The issue was closed because it was solved - the rendering was unified. 
The topic of that issue was not landcover=trees.


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

Re: [OSM-talk] OpenStreetMap Carto v2.33.0 release

[Paul Norman]

On 8/14/2015 7:27 PM, Paul Norman wrote:

This email is also in user diary form at osm.org/user/pnorman/diary/35589
where issue numbers are linked.


I forgot to mention in the earlier message, please file any bug reports 
at https://github.com/gravitystorm/openstreetmap-carto


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

[OSM-talk] OpenStreetMap Carto v2.33.0 release

[Paul Norman]

This email is also in user diary form at osm.org/user/pnorman/diary/35589
where issue numbers are linked.

OpenStreetMap Carto 2.33.0 has been released. This release focuses on
cartographic style improvements, but the release notes also include 2.32.0.

The biggest changes are

- A randomized symbology for forests for natural=wood and landuse=forest
  #1728 #1242

  A long time in the works, this improvement has finally landed. The two
  tags were merged - they are indistinguishable to the data consumer.[1]
  A randomized symbology was first suggested by SK53[2] at SOTM-EU 2014,
  and this feature would not have happened without his extensive research,
  or imagico's tools for creating an irregular but uniformly distributed
  and periodic dot pattern[3]

- Rendering minor roads and service rail later for mid-zoom clarity
  #1682 #1692 #1676 #1647

  As all residential, unclassified, and service roads in a city became
  mapped the rendered view became over-crowded, bloblike, and difficult
  to read.

- Unification of footway/path and rendering surface of them

  The mess that is highway=path is well-known[4], and it is necessary
  to do some kind of processing as a data consumer. A distinction is
  now made between paved and unpaved footways.

- Rendering of Antartic ice sheets from shapefiles #1540

  Ice sheets in Antartica are a bit of a special case, and pre-generated
  shapefiles are now used

- Mapnik 3 preperations #1579

  The style is not yet fullly tested with Mapnik 3 and we don't claim to
  support it, but several bugs were fixed. Most of the work was done on
  the Mapnik side

- No longer rendering proposed roads #1663 #1654

- Power area colour adjusted #1680

- Better place label order #1689

- meadow/grassland and orchard/vineyard color unification #1655

- Render educational area borders later #1662

- New POI icons

A full list of changes can be found on Github at
https://github.com/gravitystorm/openstreetmap-carto/compare/v2.31.0...v2.33.0)

[1]: 
https://github.com/gravitystorm/openstreetmap-carto/issues/647#issuecomment-52816195

[2]: http://sk53-osm.blogspot.ca/2014/09/woodland-cartography.html
[3]: http://www.imagico.de/map/jsdotpattern.php
[4]: http://www.openstreetmap.org/user/Richard/diary/20333

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

Re: [OSM-talk] Facebook uses OpenStreetMap

[Paul Norman]

On 7/16/2015 6:42 PM, Dongpo Deng wrote:
Does anyone have ideas why Facebook uses OSM for their checkin service 
in some Asian countries including Taiwan, Japan, Korea, and China?
Probably one of the typical reasons, better data in what they care 
about, different cost structure, or a different license model. It's good 
to see.


I'm not surprised to see Facebook move in Asia first. The traditional 
international proprietary data vendors have weaker data in much of the 
region, and the national proprietary data sources are country by 
country, and may not suit them.



In Taiwan, just some areas are patched OSM on Here Map, e.g. Taipei City.
Do you mean there are parts that are using both OSM and Here at the same 
time? I didn't see any, but am not familiar enough with the area.


What I saw looked like a regional cut - taking parts of Asia from OSM. 
This is like Flickr did in Bejing with OSM, or MapQuest does with North 
America from TomTom and the rest of the world from OSM.


I did see some quite crude cuts between what looked like two different 
map styles, but those didn't seem to align with usage of Here vs usage 
of OSM.



Because of that, we get more and more Notes for reporting errors.

Are people reporting what is a bug with Here data on OSM?

In North America we get some reports coming from Craigslist users who 
have had a bad result from their geocoder. But they're easy to close, 
and I think it's helped with more real notes. More error reports is a 
great thing.


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

Re: [OSM-talk] Issue-Tracker for http[s]://www.openstreetmap.org

[Paul Norman]

On 7/16/2015 11:59 AM, Matthijs Melissen wrote:

There are actually three thing you see onwww.openstreetmap.org: the
map data, the map tiles (rendering style), and the website itself.

There's a couple more
- Nominatim, used for Search and Where am I?
- Various routing engines, used for directions

In the case of those, before reporting a bug you should first reproduce 
it on their sites.



To report bugs in the map data, use the 'Add a note to the map'
button.

osm.org/fixthemap is another good resource

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

Re: [OSM-talk] New hardware - new possibilities?

[Paul Norman]

On 7/4/2015 8:49 PM, Daniel Koć wrote:
Or maybe the donation was meant just to keep us running as we are 
today with no further development plans? 
The donation drive is for hardware resources, not for development 
resources. In fact, development is defined as being outside the scope of 
the Operations Working Group, who organized the details.


The additional rendering capacity should allow the sysadmins to bump the 
style version in use on tile.osm.org more freely, which should allow the 
OpenStreetMap Carto maintainers to release more frequently.


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

Re: [OSM-talk] Mappers and apps should focus on relations at the very start

[Paul Norman]

On 6/27/2015 1:14 PM, Fernando Trebien wrote:

Actually no, the server checks for circular dependencies, and a
relation pointing to itself is a cycle. Try it, the server returns a
validation error.
Nothing in the OSM data model prohibits a relation that references 
itself, or relations that form a cycle.


As an example, see https://www.openstreetmap.org/relation/1368401 which 
contains itself twice. Longer cycles are also possible.


I can't imagine a case where a cycle is sensible, and they are often 
difficult to delete, first requiring modifying the relations to remove 
the cycle, then deleting the relations.


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

Re: [OSM-talk] getmap in osm mode

[Paul Norman]

On 6/17/2015 10:41 AM, Daniel Koć wrote:
getmap works with so called public static image APIs, which are 
provided by Mapquest and Google. AFAIR, OSM does *not* provide such 
an API - at least at last time I checked. But, I've read that OSM now 
provides direct routing. If they would also provide an static image 
API, ... ;-)


So what about that "public static image APIs" - do we have it (or will 
we some day)? 


OSM doesn't provide APIs except the editing API*. The routing on osm.org 
is from third-party providers using OSM data. I believe MapQuest Open 
has a static image API like MapQuest.com, except using OSM data 
globally. That would probably be very easy for them to implement, as it 
would basically reuse their existing MapQuest code.


There is the /cgi-bin/export endpoint on the tile servers, but that is 
not suited for an application like this.


* And arguably tile.osm.org
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Reporting routing problems

[Paul Norman]

On 5/28/2015 11:25 AM, Daniel Koć wrote:


With MapQuest it was much harder to find how can I report another bug. 
Finally I have found "Residential Map or Route Errors" link on Support 
page ( https://support.mapquest.com/hc/en-us - looks like the link 
itself is dynamic, because it has issue number included). Help service 
was as quick as in OSRM, but they said MapQuest currently support is 
only active for USA and Canada and while they hope international 
routing will be also supported, they can only recommend me Open 
MapQuest with OSM data. =} After I said that I originally came from 
OSM itself, the help line operator said that he will "share this with 
our routing team but please note that we are not actively supporting 
international routing right now so I unfortunately can't make any 
promises as to when we might get to this." Maybe our technical team 
should talk with theirs to make better feedback channel available?


I would suggest reproducing the issue on open.mapquest.com and providing 
a link to that route when reporting.


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

Re: [OSM-talk] Tagging FOR the renderer

[Paul Norman]

On 5/17/2015 3:14 PM, Daniel Koć wrote:

I have no idea how you'd apply P2P to map style design. It sounds like
you; ve heard of a great technology, and want to apply it to every
problem without fully understanding the technology and/or the problem.


I even used it once on OSM - it was called Tiles@home.
Tiles@home was not a P2P map style, it was kept in SVN and used a 
distributed rendering system. Distributed rendering is still used, 
primarily by larger scale operations. Craigslist distributes their 
pre-rendering workload among a large number of machines, and I believe 
MapBox did the same when they were pre-rendering.


I am not certain of the details after this long, but I don't think the 
Tiles@home rendering was P2P either - simply distributed.


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

Re: [OSM-talk] Territorial waters of Gibraltar

[Paul Norman]

On 4/7/2015 1:07 PM, Colin Smale wrote:
As you will have noticed by now, it's complicated. There is no "truth" 
agreed to by both sides, so we may need two boundaries: one according 
to Spain, and one according to Gib/UK. In between is "disputed 
territory". How do we handle that in other cases?
We follow the on the ground principle. 
http://osmfoundation.org/w/images/d/d8/DisputedTerritoriesInformation.pdf is 
information we have for officials from countries with disputed territories.


Admittedly the on the ground principle is generally clearer on land than 
on water and there are some cases which are more complicated.


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

[OSM-talk] Release openstreetmap-carto v2.29.0

[Paul Norman]

Today version v2.29.0 of the OpenStreetMap Carto stylesheet has been 
released.


Changes include

- An entirely new natural=tree and tree_row rendering, based on the
  osm-fr style (#978)
- New water features styling (#991)
- Better matching of icon colours and text colours (#1354)
- Rendering arrows for implied oneway on roundabouts
- Halo appearance improvements
- Cliff rendering improvements
- Improvements to COALESCE ordering to prevent unrendered tags from
  blocking rendered ones (#1349)
- Improvements to tourism=viewpoint rendering when present on features
  with other tags
- Increasing living street contrast
- Intermittent river low zoom improvements
- Fixed integer out of range error causing z0 to be blue
- More SVG icons
- Aeroway widths
- Lots of SQL cleanup

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v2.28.1...v2.29.0

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

where they will be tracked. Mailing list comments may not get properly
tracked, so please report problems to the issue tracker.

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

Re: [OSM-talk] Voting on voting system for proposals

[Paul Norman]

On 3/18/2015 2:43 PM, Clifford Snow wrote:
Since you are involved with updating the rendering, can you tell us 
the process to decide what should be rendered? I realize that part of 
it must be stylistic, but what outside influences cause you to include 
a tag as part of the standard rendered OSM tile?
I should preface this by stating that these are my opinions, and I know 
other OpenStreetMap Carto maintainers look at it differently. They are 
also not the opinion of my employer, MapQuest, and the MapQuest Open 
style has different cartographic goals.


There are no policies on what is rendered, and types of features are 
decided on a case by case basis.


Normally the process of deciding to render a feature and deciding to 
render a particular tag are separate. You might decide you want to 
render bus stops, but also find that in the region you're rendering 
there is a GTFS feed with better data. In OpenStreetMap Carto, these two 
steps are more entwined. We're aiming at mappers and want to avoid 
additional sources of non-OSM data.


A first consideration is technical. Some of the crazy relation types out 
there are not designed in a way that they can be reasonably rendered 
with a standard toolchain. If I can't figure out how to write the SQL to 
be able to get a data layer suitable for rendering, it almost certainly 
won't be rendered.


I'm only interested in rendering established tags. The primary indicator 
of this is usage. There are some exceptions to this like national 
capitals, where there are only many of them. My view is that a tag 
should be able to obtain reasonable usage numbers on its own merits 
without being rendered. I also look beyond taginfo numbers to see if 
they are being skewed by a small number of contributors, mechanical 
edits, or a bulk import.


We don't want to encourage difficult to consume tagging approach. This 
is why we will not use disused=yes. (#111)


The wiki is a source I use, but just one among many.

A good read is Andy's comment about changing tags: 
https://github.com/gravitystorm/openstreetmap-carto/issues/230#issuecomment-29238913. 
It is related.


And of course, all of this is done in a limited amount of available 
time. If I decide to work on something with the style it means I'm not 
working on a different part of it. It's zero sum for me, and I always 
have more I can work on. Rendering new types of features is about bottom 
of the priority list for me right now.



Would you render a tag without a wiki entry, or with just a proposal?
In principle, if it were an established tag? Yes. It's very unlikely an 
established tag would not have a wiki page.
How does the fact that it may be useful to specific groups, ie, 
cyclists which has its own style impact your decisions?
I don't particularly consider the presence of specialist styles. There 
are styles for most topical interests these days.


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

Re: [OSM-talk] Voting on voting system for proposals

[Paul Norman]

On 3/18/2015 2:40 AM, Martin Koppenhoefer wrote:
I'd like to point to the tagging mailing list, where there is 
currently a discussion going on, whether the current voting system for 
voting proposals should be changed.
Just as a clarification, this is for voting on what it takes to indicate 
a tag is approved on the wiki. It is not about if a tag is approved for 
use, as there is no such thing.


No approval is needed to create a new tag, to render a tag, or to 
otherwise do something with a tag that has not passed a wiki vote.


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