[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

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

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

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/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] 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

[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] 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

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

[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

[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

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

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

[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

[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

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

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

[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

[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

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

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

[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] 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

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

[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] 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

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] 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] 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] 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] 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] 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] 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] 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] 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] admin_level 4 rendering

[Paul Norman]

Subarea members are a pain and duplicate geographic information, but I don’t
think they cause any performance issues, largely because all the relevant
tools ignore them.

 

From: Pierre Béland [mailto:pierz...@yahoo.fr] 
Sent: Monday, April 07, 2014 12:29 PM
To: Felix Delattre
Cc: Talk Openstreetmap
Subject: Re: [OSM-talk] admin_level 4 rendering

 

In the relation for Nicaragua (id=287666), there are objects with role
subarea.  For example, addition of subarea role for Chontales is redundant
with Relation  Chontales (id=2194866). I dont know if this would fix the
problem, but you could remove the redundant subarea members from the
Nicaragua relation.  Developpers that know how relations are rendered could
tell what is the impact of redundant references adding subarea elements to
the main relation.

 

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

Re: [OSM-talk] Are there some infos about the outtake ?

[Paul Norman]

> From: colliar [mailto:colliar4e...@aol.com]
> Sent: Thursday, April 17, 2014 7:15 PM
> To: talk@openstreetmap.org
> Subject: [OSM-talk] Are there some infos about the outtake ?
> 
> Hey
> 
> Are there any infos available about the current outtake ?
> 
> I am just curious if I will have a chance to upload soon or if I should
> save, go to bed and try tomorrow again.
> 
> Many thanks to the admins for there nice job.

The database server currently appears to be down. I have no additional 
information.


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

Re: [OSM-talk] Redaction of inproperly imported protected areas data

[Paul Norman]

I held off on the redaction because there was some hope of getting 
Permission from the WDPA, but it looks like they won't be licensing 
the data under an open license, or giving us special permission.

> -Original Message-
> From: Paul Norman [mailto:penor...@mac.com]
> Sent: Wednesday, November 06, 2013 3:46 AM
> To: talk...@openstreetmap.org; talk...@openstreetmap.org; talk-
> p...@openstreetmap.org; 'OSM Talk'
> Cc: d...@osmfoundation.org
> Subject: [OSM-talk] Redaction of inproperly imported protected areas
> data
> 
> During other work the DWG recently became aware of an improper import of
> data about protected area from World Database on Protected AReas (WDPA),
> a proprietary data source. I had initially thought the data was confined
> to Bolivia, but it appears to be in the following countries:
> 
> - Mexico
> - Guatemala
> - Honduras
> - Ecuador
> - Peru
> - Bolivia
> 
> Unfortunately, there's not really much to do but remove and redact the
> data as WDPA was previously contacted and declined to license their data
> under an open license.
> 
> This message is just to let people know as it impacts more than one
> country.
> 
> I expect all of this redaction to be done by the end of the week.
> 
> It may sound like redacting data out of OSM is an easy thing to do but
> apart from using up time better spent on other aspects of OSM,
> redactions often also damage data that was built on top of an improper
> import. Redactions also tend to lead to confusion, with people reporting
> vandalism because something that used to be on the map isn't any more.
> 
> Paul Norman
> For the Data Working Group
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


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

[OSM-talk] Organizational mapping policy

[Paul Norman]

We have more and more organizations and businesses mapping in OSM. 
Multiple organizations have been conducting paid editing in Europe and 
the US. This generally comes to light *after* complaints are made - with 
the company usually not identifying who they are, what their goals are, 
and what they want, beforehand. There have also been difficulties 
determining what has been mapped on behalf of an organization. 

We will likely see more of this type of editing in the future, and while 
not necessarily bad, there are differences between it and normal 
editing. Recent events in a project similar to OpenStreetMap - Wikipedia 
- have demonstrated that the participation of organizations in data 
editing can occasionally lead to misunderstandings or disharmony in the 
project, particularly where a lack of transparency is involved. 

For this reason the DWG is considering if it is necessary to issue 
guidelines for organizational editing. Some previous discussion is at 
http://lists.osm.org/pipermail/osmf-talk/2013-November/002344.html 

There are some activities we do not want to cover in the guidelines

- Unorganized editing by employees, e.g. a shop owner adding their shop
  or nearby details to the map

- Editors mapping in response to a contest or similar where the contest
  organizer does not have the power to require them to edit 

- Individuals who, on their own accord, decide to participate in an 
  organised effort or challenge, like local mapping parties, Mapathons, 
  HOT projects, etc

Some possible guideline requirements could involve 

- Disclosing those who are directing them (e.g. employers or who they 
  are contracting for) on the users page

- Creating a wiki page with links to user pages of users mapping under 
  an organization's direction

- Requiring those working on broader projects to communicate and get 
  feedback from the community before starting

- Requiring disclosure of proprietary third-party sources used. 
  Organizations may have data from third parties that they can legally 
  use when contributing to OSM, but aren't able to directly show others
  the data

- Maintaining separate accounts if doing both personal and organizational 
  editing

The extent of editing activities covered is something else that needs to 
be discussed.

Some types of activities that *could* be covered are

- Teachers requiring their students to edit OSM as part of a course

- Consultants editing for multiple clients

- Being required to edit as part of an employment relationship

SEO spammers would be covered by this policy, but are not the target. 
They would ignore it, so we'll just end up using the existing tools 
of reverting and blocking.

Paul Norman
For the Data Working Group



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

Re: [OSM-talk] Organizational mapping policy

[Paul Norman]

> From: Mikel Maron [mailto:mikel_ma...@yahoo.com] 
> Sent: Wednesday, May 14, 2014 2:07 PM
> Subject: Re: [OSM-talk] Organizational mapping policy
> 
> I have to say, my initial reaction to this proposal was that it was 
> heavy handed, unnecessarily punitive, over reaching, and not in the 
> spirit of OSM. A cure worse than the disease. 

To clarify (and I could have made this more explicit) there is *not* a 
proposed policy here. 

The DWG is considering if it is necessary to issue guidelines, it is not 
decided that something needs to be issued or the contents of anything 
we'd issue. The items listed are possible requirements and possible 
covered activities only. It is extremely unlikely that any policy 
resulting from this will include all the possible requirements and cover 
all the possible activities. I'm personally against some of the 
requirements listed as possibilities. 



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

[OSM-talk] Canadian OSM POI quality

[Paul Norman]

I was curious how complete OpenStreetMap shop data was, so decided to
do an analysis for some Canadian chains.

The results were mixed. Starting with a Canada extract, I processed the
data into PostGIS and ran queries against name, brand and franchise for
objects where amenity, office or shop was null. Brands which have recently
changed names (e.g. Zellers/Target) were avoided.

OSM completeness varied from 7% to 81%, with no overwhelming trends. The
four major fast food and restaurants chains considered ranged from 33%
to 51%. Shops opening and closing change the accuracy of these results,
and the accuracy of the external sources for number of shops may be
variable.

Method
==

The geofabrik extract for Canada was imported with osm2pgsql with a
custom .style file containing name, operator, brand, franchise, amenity,
building, office and shop columns. The last four columns caused an object
to be placed in the polygon table. After import, the tables were filtered
to remove rows where there was not an amenity, office, or shop tag.
Appropriate indexes were added. A view was created combining the two
tables and giving lower-case versions of the name, operator, brand and
franchise tags.

Queries of the following form were run
  SELECT COUNT(*) FROM shops
WHERE lname LIKE :'name' OR lbrand LIKE :'name'
  OR lfranchise LIKE :'name';

:'name' was substituted in by psql for what I was searching for. For
example, 'mcdonald%' for McDonald's. The queries used were intended to
catch all possible shops even if it resulted in false positives. Brand
selection was not done in any systematic manner.

Public sources were used for the true number of shops of a particular
chain, generally Wikipedia or public data aggregators.

Results
===
   OSM   True   Completenmess
Tim Horton's  1480   4304   34%
Subway 849   2563   33%
McDonalds  722   1417   51%
Starbucks  592   1363   43%
Both OSM and Google use both Starbucks and Starbucks Coffee
A & W  292800   37%
Domino's67383   17%
Wendy's224369   61%
Burger King150281   53%
East Side Mario's   46 85   54%
Milestones  32 44   73%
Chili's 10 16   63%

Sears  105   15707%
Rona   122500   24%
The Bay 50421   12%
Walmart265382   69%
Home Depot  95180   53%

Canadian Tire  400491   81%
May be double-counting automative centers.
Chapters47233   20%
Sleep Country   22179   12%
London Drugs54 78   69%
May be double-counting some stores with a pharmacy inside

Remarks
===

It took significantly longer to find the true number of stores than
to get results from the OSM data. Part of this is my increased familiarity
with OSM tools, but a large part is that it is not necessary to track
down many different sources to get store counts.

Although no urban/rural analysis was performed, it is generally expected
that OSM is more complete in populated urban areas than low-density rural
areas, and completeness in these urban areas are often more important
for many uses.

No proprietary data sources were available for comparison, but it should
not be assumed that they are any more complete, nor that their name or
similar tagging is any more consistent. As an example, Google's data was
observed to use both "Starbucks" and "Starbucks Coffee" for the coffee
chain, sometimes having both for what was really the same location.

The tools used to generate counts could easily be used to extract the
shop data to work with.

Improving the data
==
Inconsistent tagging was observed with some shops, such as variability
between amenity=restaurant and amenity=fast_food. This should reflect
differences between locations but may not. Inconsistent names were also
observed, such as "Walmart", "Wal-mart", and "Wal Mart". These issues
are not as significant as the large percentage of missing shops.

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

[OSM-talk] openstreetmap-carto updates

[Paul Norman]

Version 2.15.0 of the openstreetmap-carto was just released

Full changes: 
https://github.com/gravitystorm/openstreetmap-carto/compare/v2.14.0...v2.15.0


There were a lot of behind the scenes cleanups to the style, but two 
notable changes are landuse recolouring and track restyling.


Landuse colours have been all over the place with the style, with no 
consistency in lightness or colourfulness (chroma).


The recent changes (#599) bring consistent lightness and more consistent 
chroma to residential, retail, commercial, industrial, farmland and 
farmyard. I've also started expressing colours in a perceptual 
colourspace (Lch), although they have to be converted to RGB in the 
style. Another change is borders, which are now much more subtle, 
particularly for unnamed landuse. They have also been made consistent 
across the landuses changed. For farmland, this should help encourage 
tagging of individual fields.


Track rendering based on tracktype has been nonsensical. You can see an 
example at 
https://github.com/gravitystorm/openstreetmap-carto/issues/136#issuecomment-25240763 
of the old types side by side. The changes make it a consistent 
progression from tracktype 1 to tracktype 5, with alternating short and 
long dashes for no tracktype. If you don't like the unknown tracktype 
rendering, go survey it and set it :)




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

[OSM-talk] Proposed repeated mechanical edit: Empty relations

[Paul Norman]

I'm proposing a regular mechanical edit to remove relations over two 
days old with no tags, no members, and that are version 1. The reasons 
for this are hopefully obvious. They should only exist through editor 
bugs, and contain no data from users of any kind. There are currently 
1.4k relations like this.


The technical details are at 
http://wiki.openstreetmap.org/wiki/Mechanical_Edits/pnorman#Repeated_empty_relation_cleanup. 
I've done a similar mechanical edit in the past.


In case of a conflict (another user editing them at the same time) the 
API will reject the changes and I'll just re-generate the list. I 
consider this very unlikely, as the only way you can do anything with 
the relations is to know the machine-generated ID.


Before actually conducting the edit, I want to see what editors were 
used, and submit bug reports if there's any regular problems.


I'm calling this a regular mechanical edit rather than a bot because it 
doesn't have the level of automation to be a bot.


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

Re: [OSM-talk] Proposed repeated mechanical edit: Empty relations

[Paul Norman]

On 2014-06-16 3:55 PM, Clifford Snow wrote:
I'm curious, can you get a count of empty relations by editor and age? 
Basically, current, and then yearly?


There have been past cleanups, so what you're talking about would need 
to involve looking at historical data, which I don't have loaded up, so 
won't be doing. Looking at only those in the current data right now 
wouldn't be useful.


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

Re: [OSM-talk] Organizational mapping policy

[Paul Norman]

On 2014-06-20 12:47 PM, Johan C wrote:
> However, I don't think it's a good idear that the DWG can decide on
> policies/guidelines/requirements etcetera because it's the same DWG that
> uses these policies/guidelines/requirements for enforcing.

The DWG does not decide policies. That is one of the roles of the 
Management team[1].


> As broadly as you describe it, you could also be implying a policy onto
> HOT. For example, I have been armchair mapping in the Philippines, 
trying
> to do my best using sometimes bad satellite imagery (cloudy) to map 
roads

> in the Tacloban area. Or it could have also been tracks (difficulty to
> see sometimes), whereby I tried to use a tracktype which I'm sure was 
not

> always correct all the time. HOT is a larger organization, and I was not
> directly working for HOT but by using the tasking manager I was a remote
> mapper.
> You could also mean Maproulette, which seems to be a nice tool (I've 
never
> used it) but which also promotes armchair mapping. And what about 
quality

> assurance tools: even when they are not signalling things right some
> mappers desperately want to solve any warning/error they come up with.

I'm glad you brought up the examples of armchair mapping through the TM,
MapRoulette, and QA tools. All of these are addressed in the discussion 
paper,

which specifically excluded them from the scope.

> Of course you can reply saying I'm exaggerating. But is the DWG 
_proposal_


Having written regulatory guidance professionally, what was sent out was
sent is closest to a discussion paper, not a policy proposal, intended to
illicit viewpoints, not advocate specific requirements. Points may be
included because members of the community have brought them up, not because
they came from a member of the DWG.

[1]: 
http://wiki.osmfoundation.org/wiki/Management_Team/Statutes#Policy_Procedure



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

Re: [OSM-talk] Proposed repeated mechanical edit: Empty relations

[Paul Norman]

I completed the edit without issues.

https://github.com/openstreetmap/iD/issues/2270 opened for one source. 
JOSM had a few too, but those cover more versions so don't show up at 
the top.


I manually handled relations which had other relations parents, and in 
ever case it was an error of some kind. Most of the parent relations 
themselves had no tags and no other members.



On 2014-06-16 1:17 PM, Paul Norman wrote:
I'm proposing a regular mechanical edit to remove relations over two 
days old with no tags, no members, and that are version 1. The reasons 
for this are hopefully obvious. They should only exist through editor 
bugs, and contain no data from users of any kind. There are currently 
1.4k relations like this.


The technical details are at 
http://wiki.openstreetmap.org/wiki/Mechanical_Edits/pnorman#Repeated_empty_relation_cleanup. 
I've done a similar mechanical edit in the past.


In case of a conflict (another user editing them at the same time) the 
API will reject the changes and I'll just re-generate the list. I 
consider this very unlikely, as the only way you can do anything with 
the relations is to know the machine-generated ID.


Before actually conducting the edit, I want to see what editors were 
used, and submit bug reports if there's any regular problems.


I'm calling this a regular mechanical edit rather than a bot because 
it doesn't have the level of automation to be a bot.


___
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] The biggest violation of OpenStreetMap, ever.

[Paul Norman]

On 2014-07-09 11:42 AM, Christoph Hormann wrote:

On Wednesday 09 July 2014, Michael Reichert wrote:

The website now has an attriution in the lower right corner:

© Geopoi, Map Data: © Here, OpenStreetMap contributors

"Here" is a link to http://here.com/
"OpenStreetMap" is a link to http://www.openstreetmap.org/copyright

I think that this is not enough. Because they mix data they should
declare which data is from where. There should be a link to website
(or a pop-up) with a text like this:

It would be great if they did but nothing in the license requires them
to, the attribution requirements are fully satisfied by this.
In general a tile layer is going to be rendered from a collective 
database, of which part of is a derivative database licensed under the 
ODbL. They're obliged to disclose the derivative database, but not which 
parts of it are used, and nothing about the other databases in the 
collective database.



In general rarely any OSM based map out there tells exactly where OSM
data is used and where not, even OSMs own 'standard style' map fails to
mention the use of non-OSM data.


The style documentation does cover other sources. Also, the other 
sources are all under ODbL compatible licenses anyways, so the situation 
is a bit different as the entire set of sources can be released under 
the ODbL.



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

Re: [OSM-talk] [Talk-us] IR boundary tagging

[Paul Norman]

On 2014-07-18 10:53 PM, Paul Johnson wrote:
I should add that I do not intend on changing state boundaries, just 
mapping indian nations where I know the boundaries to lie on the 
ground, as higher than state, lower than the country, inside the US 
only, if that wasn't clear on the admin level argument.  It would 
still be possible to render a map without such excluded territory at a 
state level, since, in practice, there's a LOT of overlap in 
responsibilities and jurisdiction.


What you're proposing badly breaks admin hierarchies - hence the need to 
carve the bits out of the states if you wanted to go that route.


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

[OSM-talk] Upcoming openstreetmap-carto changes

[Paul Norman]

v2.17.0 of the openstreetmap-carto stylesheet has been released, though 
not yet deployed on tile.osm.org.


Significant changes include

* Rendering other shop values with a generic icon 
(https://github.com/gravitystorm/openstreetmap-carto/pull/604)
* Rendering wider road shields, and converting the road shields to SVGs 
(https://github.com/gravitystorm/openstreetmap-carto/pull/694)
* Cleaning up path rendering on low zooms 
(https://github.com/gravitystorm/openstreetmap-carto/pull/747)
* Improving highway=track name rendering 
(https://github.com/gravitystorm/openstreetmap-carto/pull/748)
* Rendering access=permissive the same as access=yes (or no access) 
(https://github.com/gravitystorm/openstreetmap-carto/pull/742)
* Waterway cleanups 
(https://github.com/gravitystorm/openstreetmap-carto/pull/722, and others)

* Assorted code cleanups

https://github.com/gravitystorm/openstreetmap-carto/compare/v2.16.0...v2.17.0 
has a full list of commits.


We are still very much cleaning up a lot of messy CartoCSS brought over 
from the Mapnik XML


Some interesting stuff under discussion

* Multi-line road shield rendering: 
https://github.com/gravitystorm/openstreetmap-carto/pull/750
* Rendering ref from route relationships: 
https://github.com/gravitystorm/openstreetmap-carto/issues/596
* Moving ordering of road rendering to SQL: 
https://github.com/gravitystorm/openstreetmap-carto/pull/626
* Moving to YAML for project layers: 
https://github.com/gravitystorm/openstreetmap-carto/issues/711


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

Re: [OSM-talk] Using Notes in France

[Paul Norman]

On 7/29/2014 1:32 PM, Jóhannes Birgir Jensson wrote:


Well I was surveying some area in France earlier this year and found a 
spot with missing street names so I marked it in and a JBacc1 (same 
JB?) commented  "so what" (in French Oui. Quels sont-ils ?) and 
resolved it thus.


I reopened it with a comment of my own, I found this approach very 
strange because Map Notes are in my mind a to-do list obvious problems 
that require surveying on the ground.


The note in question is this: http://www.openstreetmap.org/note/182123
I'd consider that a useful note, and certainly within the scope of what 
notes were intended for.


On the other hand, if there were an entire region with no street names 
in the data, I'd be less inclined to consider a note pointing out a 
neighborhood missing names as useful.


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

Re: [OSM-talk] Early History of OSM

[Paul Norman]

On 8/4/2014 10:12 AM, Maarten Deen wrote:
I don't know if it is still possible to reconstruct a planet from 
pre-redaction changesets [2], 
The redaction doesn't matter for reconstructing old data - for pre-2007 
we're talking API v0.3 data or earlier, with segments.


http://commons.wikimedia.org/wiki/File:KT13_Area.4.png is the oldest 
published map from OSM I know of, back in 2006.


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

Re: [OSM-talk] extracts for historical views at a specific point in time

[Paul Norman]

On 8/14/2014 6:59 AM, Richard Welty wrote:

i have a need to be able to generate mapnik tiles for
part of NY State to show what the OSM view of it
looked like maybe 2 years ago. is there a documented
process for pulling an extract like that?

Two years ago is before the redaction, so you need CC BY-SA data.

The easy way is to get the closest date from 
http://planet.openstreetmap.org/cc-by-sa/ and import it with current 
tools and the current style. You could also use the XML style as of that 
date.


If you want a date between planet files, you'll have to download one and 
update it with daily diffs.


If you're doing this for many dates, you may find it easier to extract 
from the planet dump with history, but for just one or two dates, what I 
describe is an easier method than manipulating that giant file. 
Remember, most of the history is recent and the planet from then is 
about 60% of the current planet size.


If you're dealing with data prior to version 0.6 of the API, you may 
need to downgrade osmosis to extract data from the files. For version 
0.4 and earlier, you'll need to use other tools to handle the data model 
changes. Of course, for data that old, you probably don't need to 
extract as the full planet is under 1GB.


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

Re: [OSM-talk] Carto: High zoom levels (17-19) not updated

[Paul Norman]

On 8/18/2014 11:01 AM, colliar wrote:

Is it only me or do other also see no updates of zoom level 17 to 19 of
the main mapnik renderer.

Usually, they update within minutes when reloaded but now I am waiting
for some days and nothing happens.


http://munin.openstreetmap.org/openstreetmap/render.openstreetmap/renderd_queue.html 
indicates that the is a queue for tile rendering. I believe one of the 
rendering servers is temporarily down.


There are other normal reasons why there can be a queue at other times, 
such as monthly re-rendering of low and medium zooms and stylesheet updates.


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

Re: [OSM-talk] Detrimental to the OSM database

[Paul Norman]

On 8/24/2014 2:48 AM, Lester Caine wrote:

It's not the 'brightness - it's the compressed contrast which is has
always been the problem with iD. maproulette does not link to potlatch2
which I'd normally use when not on a system with JOSM running ...
iD does not compress imagery contrast. I just checked this for local 
imagery against my debugging viewer.


I've created https://github.com/osmlab/maproulette/issues/304 about 
using the user's editor setting, as I don't believe anyone has raised 
the issue previously.


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

Re: [OSM-talk] web page element browsing history regression

[Paul Norman]

On 8/25/2014 9:43 AM, Martin Koppenhoefer wrote:

I understand that this is an open source project with volunteer contributions, 
but that part actually WAS already functional for years. Would it be possible 
to get the old browsing and history pages back, at least until someone comes up 
with an improvement?
Some people view the new pages as an improvement. Some don't. There's no 
universal opinion.



Is there support for such a partial rollback?
Leaving aside if it's a good idea, to do such a rollback would require 
someone coding it. I really doubt any of the people normally involved in 
coding on the rails port are interested, and I suspect it's not a 
trivial revert.


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

Re: [OSM-talk] Adding Wikidata tags to 70k items automatically

[Paul Norman]

On 8/27/2014 9:47 AM, Edward Betts wrote:

Does anybody have a strong preference that the edits are split up by region,
or loaded in batches?

Any objections?
When the idea of a mechanical edit to add wikidata tags to objects in GB 
came up, the local view was against it. How will you make sure your 
mechanical edit doesn't edit objects there?


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

[OSM-talk] Routing on OpenStreetMap.org: Bug checks wanted

[Paul Norman]

There is currently a pull request up for adding routing to 
OpenStreetMap.org which could use another check over for bugs. A demo 
instance is running at http://jsrouting.apis.dev.openstreetmap.org/.


Although bug reports are needed, requests to expand the scope or 
redesign the UI are unlikely to be considered unless they are 
accompanied by code.


Bugs can be reported at 
https://github.com/openstreetmap/openstreetmap-website/pull/716


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

[OSM-talk] openstreetmap-carto upgrade, new features, interesting issues

[Paul Norman]

After a delay for hardware reasons (a drive having issues in a rendering
server), the "Standard" stylesheet on OpenStreetMap.org has been
upgraded to v2.20.0 of openstreetmap-carto. As always, a full list of
changes can be found at github, via
https://github.com/gravitystorm/openstreetmap-carto/compare/v2.18.0...v2.20.0

Significant changes include

* Splitting ref tags to render refs as multi-line shields. This
  rendering is probably the best we can do until Mapnik 3 becomes
  common (#750)
* Rendering crossroad names, a feature common in parts of Asia (#813)
* Steps to fix the cyan from small water bodies at low zoom. This should
  also stop over-representing water at low zooms. (#878)
* Migrating the last of the issues from the old style over from trac
* Adjusting zoom levels where features are displayed to be more consistent
* Improved ordering of POIs (#860)
* Bugfixes

A couple more interesting issues open include

* Ways to move away from the .mml format. We are hitting limitations with
  the JSON layers file causiung difficult merge conflicts, as well as
  generally being a pain to edit, and are looking at alternatives:
https://github.com/gravitystorm/openstreetmap-carto/issues/711

* Dealing with broken boundaries where the ways lack admin_level and
  boundary tags. Worldwide coverage is reasonable, but some countries
  are missing a lot of data, principally Poland, Azerbaijan, Uganda,
  and some untouched TIGER data:
https://github.com/gravitystorm/openstreetmap-carto/issues/344#issuecomment-49535342 



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

Re: [OSM-talk] That nice popup about the State of the Map

[Paul Norman]

On 9/8/2014 11:18 AM, Cristian Consonni wrote:

it has been some days that, when I visit openstreetmap.org, I am shown
a nice box reminding me that SoTM is coming soon (see screenshot[1]),
is there a way to use this system to promote local events (say local
State of the Map conferences?).
There are two issues with this. First, a technical one - no one has 
written the code to do so. This is, for obvious reasons, an absolute 
hard requirement.


The second one is a policy one, on what to show, and to whom. SOTM is 
easy, as it's an OSMF event. It'd probably be annoying and dilute the 
value of the spot if there was a banner there the majority of the time. 
Including past non-OSMF events on the front page has been contentious, 
but we now have a Local Chapters template agreement, which might make 
that easier as we could tie that in, now having a definition for a local 
chapter.


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

Re: [OSM-talk] That nice popup about the State of the Map

[Paul Norman]

On 9/8/2014 11:45 AM, Cristian Consonni wrote:

Both are absolutely good points, for the first one can I suggest to
use the same system that is used on Wikimedia websites?
https://meta.wikimedia.org/wiki/Geonotice
Code to add geonotices to a Mediawiki wiki is unlikely to be directly 
applicable to the ruby on rails port which runs the website. I doubt 
it'd be hard to code, but again, it's a hard requirement that someone 
code it .


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

Re: [OSM-talk] That nice popup about the State of the Map

[Paul Norman]

On 9/8/2014 12:03 PM, Cristian Consonni wrote:

(Ruby on Rails? i thought it was PHP!)
With the exception of some API calls in C++, the code powering the 
website is all Ruby on Rails. There's also obviously user-facing 
Javascript. The map rendering and geocoding are not part of the website 
on a technical level, and have their own server stacks.

(So, where's the code of the website?)
The code of the website, as well as setup and contributing instructions 
are all at https://github.com/openstreetmap/openstreetmap-website


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

Re: [OSM-talk] keys with multiple values

[Paul Norman]

On 9/12/2014 3:24 PM, moltonel 3x Combo wrote:

To me there's very little semantic value in distinguishing between
name_2 and alt_name. Even old_name and loc_name arguably don't bring
much to the table (I do see the nuance, but it doesnt seem to be worth
the complication). We've got the same problem with the ref tag and
many others.
I believe with TIGER these were not alternate names, but different 
names, none of which were clearly main or alternates in the data. It's 
one of those things that makes raw TIGER data a pain to work with.


That situation is distinct from when you have a primary name and 
multiple alternate names, although in practice many of the TIGER cases 
had a primary name, or one of the alternate names wasn't really a name.


TIGER is also not where to look to for good tagging practices. For 
various reasons, there were numerous problems with the tagging.


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

Re: [OSM-talk] keys with multiple values

[Paul Norman]

On 9/15/2014 9:45 AM, moltonel 3x Combo wrote:

Supporting multiple values natively in the osm data model would
provide a clean and efficient solution, but updating all the tools to
support it would be a huge undertaking.
It's not going to get supported by most data consumers. This isn't a 
question of upgrading tools, this is a question of tools relying on a 
key=>value store, a single column, or some other external dependency 
which doesn't allow multiple tag values. I believe when the API did 
support multiple values for one tag almost no data consumers supported it.


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

Re: [OSM-talk] keys with multiple values

[Paul Norman]

On 9/15/2014 10:29 AM, colliar wrote:

Of course we could define some escape character
>like the famous backslash but ... I don't even want to write that stupid
>idea down.

Do not think that is stupid but one solution for a rare situation. If it
is properly described on the wiki, there should be no problem.
Anyone who does handle a semicolon is almost certainly going to be 
simply doing a string split on ;, regardless of what the wiki says, 
rendering the wiki wrong if it were to say that.


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

Re: [OSM-talk] Wood & Park mapnik carto anomaly?

[Paul Norman]

On Sep 16, 2014, at 06:33 AM, "Dave F."  wrote:

On 16/09/2014 13:41, Matthijs Melissen wrote:
       > In general, we render smaller landuse on top of larger landuse.

I find it surprising something as arbitrary as size is used as the 
defining factor. Comparing actual tags would surely make more sense.


As a recent bug 
(https://github.com/gravitystorm/openstreetmap-carto/issues/950) has shown, 
it's important to have *some* well-defined ordering in cases where the ordering 
could make a visual distinction, or the rendered result is undefined and 
potentially not deterministic. This can lead to subtle bugs with clipped labels.

The two criteria are OSM ID and area. The first is truly arbitrary being a 
computer-assigned number, while the second is well-founded and is the standard 
way to order within a layer. 

What you're more interested in is why are parks and trees both in the same 
landuse layer. It would certainly simplify the SQL 
(https://github.com/gravitystorm/openstreetmap-carto/blob/master/project.yaml#L102)
 to split it up into different tags, but the problem is there is no universally 
acceptable ordering of tags. You've pointed at a case where it'd be good to 
have trees on top of parks, but I can point to cases where parks should be on 
top of trees.

There's another layer for overlays like military or nature reserves but without 
trying it out, I'm not sure if that'd add clarity. Someone is welcome to try it 
out 
(https://github.com/gravitystorm/openstreetmap-carto/blob/master/CONTRIBUTING.md)

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

Re: [OSM-talk] Wood & Park mapnik carto anomaly?

[Paul Norman]

On 9/17/2014 7:33 AM, Dave F. wrote:

I wouldn't describe size based ordering as 'well defined'.
The polygon table has no column or combination of columns which is 
guaranteed to be unique. We only need to have a well defined ordering 
within a meta-tile that is consistent across boundaries, not globally, 
and way_area works well for that. Thanks to precision limits in the data 
and conversions to Web Mercator two apparently identical area polygons 
will probably slightly differ in the exact calculated area, and two 
polygons identical in WGS84 area may not be identical in Web Mercator 
area. If two polygons are exactly the same area they probably are the 
same geometry, which is a special case.


A sort order that is well defined in nearly all cases* would be both way 
area and osm_id, but the additional ordering term would probably 
negatively impact the speed and memory of the sort.


* Again, there are certain exceptions in theory.

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

Re: [OSM-talk] Multilingual Map Demo working again

[Paul Norman]

On 10/19/2014 1:40 PM, moltonel 3x Combo wrote:

What's required to switch this from "demo" to "used on default osm.org
layer" ?
I don't believe anyone is currently evaluating alternatives to the 
current stack for tile.osm.org.


I think most of those who might are busy with vector tiles these days.

Switching rendering stacks with the current load might require a third 
rendering server for the transition and increased capacity.


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

Re: [OSM-talk] [Osmf-talk] A Better Map

[Paul Norman]

Alex, the LWG would love to work with you on fixing any confusing if you're 
interested in resuming work on the guideline - currently it lies abandoned with 
the feedback needing to be integrated.

On Oct 22, 2014, at 05:33 AM, Alex Barth  wrote:

Steve - would love to work on fixing the license with you so addresses in OSM 
make sense in the first place. Right now you practically can't use OSM for 
permanent geocoding. See also:

https://lists.openstreetmap.org/pipermail/legal-talk/2014-July/007900.html 


On Wednesday, October 22, 2014, Steve Coast  wrote:
Why are we here on these mailing lists? Why do we spend so much time making 
maps? I think ultimately because it’s fun. It’s a neat hobby and we’re making 
the world a slightly better place.

You need the right environment for things to be fun. Someone has to install the 
toys in the playground. Someone needs to pay for the slides and install the 
swings so that the kids can run around. Then someone else needs to fix them 
when they fail and make sure you don’t break your neck unexpectedly.

In the past I’ve tried hard to make OSM a fun playground, by doing things like 
taking all the warning labels off and letting people do whatever they like. 
Things like open tagging or letting anyone edit, which were crazy ideas in 
2004. I’ve also at times been responsible for it not being fun. Partly because 
I was a kid learning the hard way and partly because sometimes you need to make 
decisions.

I agree that in some ways OSM isn’t a fun playground right now. But that 
doesn’t mean it can’t be again.

We had a lot of fun with our swings and our slides. But now there are a lot 
more people to join the fun from far away places and we’re older. Maybe we now 
prefer bumper cars and video games to the old swings and slides.

We should keep the swings and the slides. People new to the playground will 
still enjoy them. But we should also build a bumper car arena and maybe a video 
game arcade. Sometimes we might go back and play on the slide too. We need some 
new skills to build these new toys.

Together, we need a mission and then a couple of course corrections to make it 
happen.

I think addressing should be our mission. We built the worlds best display map 
already. We won. If you print out any OSM map of practically anywhere, it’s the 
best. But we can’t find anything on it without comprehensive and global 
addressing information. It’s the hidden data behind the map we now need to go 
after. All the other things we need to do are also good things. Diversity in 
all it’s forms, faster servers, better tools, easier documentation and more.

A clear mission provides a framework and guidance for achieving those things. 
“Map more stuff” got us very, very far. But now, we should focus on what’s 
stopping us replacing proprietary maps. And that is addressing.

How would we go achieve that?

There are two basic fixes. Make the board functional and give the board 
bandwidth.

The board is too big. It grew for good reasons but now it’s just hard to 
achieve anything. Seven people mean that if everyone speaks for five minutes in 
a conversation on some issue, you use over half an hour. In an hour-long 
meeting that means you can barely discuss two things. Ignoring all the other 
issues, just the pure mechanics shows you how hard it is to talk through 
something let alone achieve a consensus. The board needs to be 3 people. 5 at 
maximum.

Being on the board is a difficult job, especially as a volunteer. Most people 
aren’t used to such roles. They may think like I did that they need to please 
everybody all the time. They aren’t able to attend meetings because they have a 
day job and other life commitments. The board needs to meet in person regularly 
with a facilitator and also have guidance about what it means to be on a board. 
We can’t expect volunteers to naturally figure all this stuff out by themselves 
and then also devote the time to also achieve goals.

The board needs paid staff. There are a variety of things those paid staff can 
do which the board can decide. It’s clear that there are things that volunteers 
don’t have fun doing and therefore they don’t happen at all, but are still very 
important for a functioning organization. Having paid staff isn’t about 
deprecating volunteer involvement, it’s about plugging the gaps. It’s not a 
perfect solution but the alternative is to rely on companies to do many of 
these things, and that really isn’t perfect either.

In terms of the mechanics,

1. Change the mission statement of OSM to be something like “The world’s best 
addressable map”
2. The board figures out how to voluntarily shrink to 3-5 people, and, meets in 
person 2-4 times a year
3. Consulting with the community on exact roles and remit, hire 1-3 people [*]

Together, we could do this in 6-12 months and finish addressing in 1-3 years. 
At that point we wouldn’t have just made the world slightly better, we would 
have put a big dent in the universe. 

[OSM-talk] Candidate reminder: Membership status and questions to canidates

[Paul Norman]

This a reminder to candidates that board members need to be members, not 
associate members. You should contact members...@osmfoundation.org to change 
your status from associate member to member if needed. I am not sure what would 
happen if someone with the most votes was not eligible to be a board member. 
Let's not find out, so make sure to mail to change it.

See 82 of the AoA, as well as probably the Companies act.

There are also a number of questions to candidates at 
http://wiki.openstreetmap.org/wiki/Talk:Foundation/AGM14/Election_to_Board. 
This has been the primary method of asking candidates questions in the past, so 
please make an effort to answer them. I haven't yet myself, but intend to this 
weekend.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [Osmf-talk] Modus operandi of the board

[Paul Norman]

On Oct 23, 2014, at 03:00 PM, Clifford Snow  wrote:

I think it is reasonable postpone elections for three months considering 
current turmoil.
 
Leaving aside any question about the merits of this, I don't believe it is 
possible. Notice has been given of the AGM, and an election must be held at the 
AGM (AOA 31). ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] The Working Groups need you!

[Paul Norman]

With the recent interest in the OSMF, I'm hoping to capitalize on this 
and boost working group participation.


There's a full list of the working groups at 
http://wiki.osmfoundation.org/wiki/Working_Groups, but I'll go over the 
list, and skills useful for participation. These aren't official, but 
gathered by working with the other WGs as well as their minutes.


Communications Working Group (CWG)
This WG handles OSMF communications, and writes blog posts for some of 
the communication channels. They handle the official tweeting too. Other 
work involves decisions and policies related to communication. Skills 
useful include writing and translation. Other skills would be those 
useful with press releases. 
https://lists.openstreetmap.org/pipermail/osmf-talk/2014-June/002418.html has 
more information


Local Chapters Working Group (LCWG)
The LCWG has been involved in setting up the Local Chapters agreement, 
and some local groups are becoming involved in officially becoming local 
chapters. I wish I could say more, but I'm not really involved, and the 
form of the LCWG may change once agreements are in place.


Engineering Working Group (EWG)
The EWG serves a dual purpose, to boost development of OSM software, and 
the discussion and coordination of pull requests to core OSM software. 
Membership is open to anyone who shows up to the IRC meetings. Activity 
has been very low lately, but if people are interested in resuming the 
EWG's work, the venue is there. Skills would include some kind of 
experience with software development.


Operations Working Group (OWG)
The OWG handles the planning of OSMF hardware. It doesn't do the 
day-to-day running of servers, nor authoring software of the servers 
which are the jobs of the sys admins and development community 
respectively. I don't think the OWG is actively looking for more. Many 
of the people in the OWG are also involved in developing OSM software, 
and I would guess that helping there would be a better route to getting 
started.


Strategic Working Group (SWG)
Currently inactive. There have been proposals to restart it, Dermot is 
the best contact there.


StateoftheMap Organizing (SOTM)
Organizes and executes the annual SOTM conference. There is the local 
team and the international team. The local team requires being local to 
the conference, obviously. I would expect the international team 
requires conference organization skills, but there have been no minutes 
published since 2010 and the members list has not been updated since the 
2013 conference.


Licensing Working Group (LWG)
The LWG handles license-related matters, external parties violating the 
license, as well as some other general legal matters. Day to day matters 
are primarily answering questions, generally by pointing at existing 
guidelines. We haven't had the time or capacity to take on issues of new 
guidelines and longer term projects like we would like to. Skills needed 
include experience with open data licensing.


Data Working Group (DWG)
The DWG handles resolution of copyright violation within the OSM 
database, and vandalism and disputes beyond the normal means of the 
community. Most of the work is dealing with disputes and vandalism 
referred to the DWG from the community. As most situations involve 
people who will be upset, a thick skin is important. Other skills 
include dispute resolution, vandalism detection, and complex reverts.


One idea for a new working group would be one for funding. This would 
take some of this work off of others who are currently doing the work, 
even though it's not their primary function. I also see numerous 
proposals for things that would require additional money, without 
discussion of how to raise the money. This includes my manifesto 
proposal of hiring a facilitator. Volunteers for this are probably best 
off contacting managem...@osmfoundation.org




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

Re: [OSM-talk] The Working Groups need you!

[Paul Norman]

On 10/27/2014 9:32 AM, Matthijs Melissen wrote:


On 27 Oct 2014 16:16, "Paul Norman" <mailto:penor...@mac.com>> wrote:

>
> With the recent interest in the OSMF, I'm hoping to capitalize on 
this and boost working group participation.


Hi Paul,

As I'm too lazy to look up the regulations, could you tell me whether 
working group members are required to be member of the foundation?



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

Re: [OSM-talk] Skybox release aerial imagery

[Paul Norman]

On 10/27/2014 2:46 PM, Michael Reichert wrote:

No. CC-BY requires an attribution at every use of the data. That's why
it is not compatible to our ODbL/Contributor Terms. OSM requires only an
attribution of "OpenStreetMap contributors" and nobody else from its
data users.

We have some government data in Germany which is available under CC-BY.
Usually the data owner granted an exemption to use the data because he
was satified by attribution at
http://wiki.openstreetmap.org/wiki/Contributors
The SkyBox imagery is CC BY 4.0, which *may* be compatible. It does not 
have the obvious problems that earlier versions of CC BY have.


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

Re: [OSM-talk] discussion: inclusion and alcohol

[Paul Norman]

On 11/1/2014 3:05 PM, Richard Weait wrote:

I read this article recently and It got me thinking.  Do we devalue
community members, or potential community members who don't drink?

A quote from the article, "When alcohol is currency, non-alcoholic
drinks are considered valueless, and the interests and needs of people
who don’t drink alcohol are easily forgotten."

Give it a read and let's talk.  Can we do better in the ways that the
article suggests?

https://modelviewculture.com/pieces/alcohol-and-inclusivity-planning-tech-events-with-non-alcoholic-options
We can do better. In fact, the OSM conferences I've been to have been 
quite bad for the expectation that everyone drinks alcohol. I can't 
personally speak to issues about safety, alcohol abuse, or being 
excluded by not drinking, but I wouldn't be surprised if they're there.


I seldom drink alcohol, or for that matter, fizzy drinks. When, on the 
rare occasion, I do drink alcohol, it is normally at most one drink. I'm 
open about this, but I'll generally use the excuse that I'm driving to 
avoid questions. I can'd do this at conferences, where it's no longer true.


I don't mind bars or pubs, provided that there are options other than 
alcohol. Unfortunately, at the past SOTM-US events I've attended, this 
is not always the case. The official after-conference events have tended 
to be loud venues with few non-alcoholic options, and those were 
difficult to obtain. When it takes five minutes to get water and it 
involves passing by multiple alcoholic drink coolers, there's something 
wrong. I have yet to go to an official after-conference event with any 
kind of juice selection. If a thousand dollars is being spend on beer, 
wine and cider, I don't think having water and a juice other than orange 
juice from concentrate is an unreasonable expectation.


Even though many local OSM social events are held in held in pubs, I've 
found them better. I've gotten fewer strange looks when I ask for 
something non-alcoholic, and they've been at venues where the focus has 
been on conversation, not drinking. I'm not uncomfortable around a table 
of people slowly drinking while talking.


As for some numbers, about a third of the people in the last meetup I 
had in a brewery-attached bar drank no alcohol that night. The inaugural 
Vancouver OSM meetup involved no alcohol at an evening social event, and 
no one complained at the lack. After it, a couple of us went to a pub, 
where we also drank no alcohol. A dozen of us, including drinkers, 
walked out of SOTM-US events with free alcohol because there was nothing 
to do there but drink. People who I've wanted to talk to at SOTM-US have 
not gone to some events because there was going to be nothing there but 
beer.


By having an alcohol focused event with no other options, you're forcing 
all of these people away.


This ended up being longer than I expected, but the more I thought about 
and talked to others, the more I realized we have a problem. I'm also 
not singling out SOTM-US because it's necessarily any worse, but because 
it's what I have experience with.


Paul


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

Re: [OSM-talk] Fix a Forest - experimental tiles from US Forest Service data

[Paul Norman]

On 11/11/2014 10:29 AM, Richard Fairhurst wrote:
I've created a set of tiles from US Forest Service road data for the 
155 US National Forests. 


It's worth noting that a green area denotes a US National Forest, which 
does not imply it's got trees, which is necessary for an OSM forest.


Thanks for putting this together.

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

Re: [OSM-talk] OSM tiles under CC BY-SA 2.0, Wikimedia requires 2.5 or later

[Paul Norman]

On 11/20/2014 1:57 PM, Leeds Tracker wrote:

Hello all,

I was about to upload a map exported from the main site (SVG using 
Mapnik style) which I see is licensed under CC BY-SA 2.0


Wikimedia Common's upload page requires 2.5, 3.0 or 4.0 (using 
https://commons.wikimedia.org/wiki/Special:UploadWizard )


Is this a problem?


No. The Creative Commons share-alike licenses contain an upgrade clause 
(4.b of version 2.0) which allows you to CC BY-SA 2.0 content under "a 
later version of this License with the same License Elements as this 
License", i.e. CC BY-SA 2.5, 3.0 or 4.0.


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

Re: [OSM-talk] Request for feedback: new building colours in openstreetmap-carto

[Paul Norman]

On 11/27/2014 2:11 AM, Lester Caine wrote:

Because the 'unclassified' icon is a dot, it is dropped on the building,
so the text is now below the building ... on the next one.
Shop text has always appeared below the icon - this is not new or unique 
to the generic icon.

It is my customers who are
commenting ... not complaints, but something has changed for them to
comment! I've been using these for the last few years.
From everything you've said about this and past changes, your customers 
might be better served by running an older version of the stylesheet on 
your tile server, or the French or German styles which are similar.


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

Re: [OSM-talk] Data filter

[Paul Norman]

On 1/12/2015 1:30 AM, Steve Chilton wrote:


Can anyone help me with filtering OSM data please?

For a project I am working on I need data on my contributions to the 
project.


How can I select ‘my contributions in UK’ and output as XML (or JSON?).

Need a file that can be imported in to standard GIS packages.

Any help gratefully received.


There's a few options, but it depends what you mean precisely.

Each object in OSM can be a mix of multiple contributions, which is the 
strength of the project. It just makes what you're asking hard, and it's 
important to define precisely what you want with your contributions.


The easy way is if you just want objects that you touched last - then 
you can do simple filtering on a UK extract, or import into a database 
with metadata and select out what you want. The latter is what I would 
do for working with standard GIS tools. This is easy, but inaccurate for 
reasons I'll come to.


You could download your changesets - but this won't be usable by any 
standard GIS packages, or in fact, by anything in isolation.


If you are after data that consists solely of your intellectual 
property, it's harder - what you've contributed is built on others, so 
separating that out isn't trivial. The tools are there, but they've 
never been used quite for that application, and the number of people who 
understand them is approximately 1.


The reason why this is a hard question is the nature of a crowd-sourced 
project, and the OSM data model.


Consider a highway which someone creates and tags with highway=primary. 
Suppose you then come along and add a name tag. Depending on what you're 
doing you might then want the entire highway included in the file of 
your contributions, even though you didn't contribute to the geometry.


Another case is if you move some nodes in a highway but don't add new 
ones. You actually haven't made a new version of the the highway.


I might be able to help more, but need more information on the use case 
first.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Error when Exporting from Share icon

[Paul Norman]

On 1/26/2015 2:58 AM, Dave F. wrote:
I don't know when it was last reviewed, but does this error have bit 
of a sensitive trigger? Has the server that runs the process been 
upgraded so it can handle a greater number of requests? If so, could 
the error's cut in point be relaxed? 
The thresholds for each server have been adjusted multiple times and 
will probably continue to be so. Even if the load cutoff is increased 
there will be times when individual render requests are rejected for a 
few days in a row - stylesheet updates being the main one. It is 
considered more important to update the map rendering than to do a 
custom render. Personally I don't have many problems generating a custom 
render from osm.org, but I'm on a different timezone and keep different 
hours, which makes it hard to compare. I also get directed to a 
different server much of the time.




For the technical details, the render code relies on the system load 
average. This is not the best metric, a better one would be one of the 
renderd supplied queue sizes (e.g. don't do custom renders if anything 
is in the dropped queue) or to integrate it with renderd, but no one has 
stepped forwards to code this.


The reason why there's the restriction in the first place is that doing 
a custom render consumes 100x to 1000x the resources of a normal tile 
request.


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

Re: [OSM-talk] Addresses interpolation

[Paul Norman]

On 1/26/2015 10:05 PM, Dmitry Kiselev wrote:
Is it a mistake or examples like this may be interpreted in some 
usable way?
I would say there's no sensible interpretation of an interpolation way 
with different nodes with different addr:street values.


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

Re: [OSM-talk] Domino's rebranding

[Paul Norman]

On 2/8/2015 2:33 PM, Paul Johnson wrote:
OK, so not sure about other markets, but at least in the US, Domino's 
Pizza has renamed itself to just Domino's.  Which presents a few 
issues, since they're not just pizza (they also do subs and wings, so 
I'm not even sure how to cuisine tag these things).


How do we want to handle retagging these?  Full scale?  Which tags?
We'd want to only retag name after the local store updates their 
signage, which may not be immediate.


The Domino's I have been to have been focused on pizza, in the choice on 
their menu, their branding, and why people go there, so I feel fine 
using cuisine=pizza.


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

Re: [OSM-talk] "guide to vandalism” in OSM?

[Paul Norman]

On 2/12/2015 6:46 AM, Michał Brzozowski wrote:

I happen to fix a lot of notes in Poland.
For me it would be impractical to check every POI that I add from notes.
It's for this reason that notes say "This note includes comments from 
anonymous users which should be independently verified".


This is an important requirement. An anonymous note can call your 
attention to something that needs to be fixed, but the actual fix needs 
to be able to be made without reference to the note.


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

Re: [OSM-talk] Big Lakes

[Paul Norman]

The Great Lakes have been discussed a few times on the local lists and the 
conclusion has been arrived at that they are best represented with 
natural=coastline.

It's important to remember that the direction of coastline ways matters (land 
on the left), and it is possible to look at a lake or island in the lake in 
isolation and tell where the water is and where the land is.

On Feb 18, 2015 8:24 PM, Jochen Topf  wrote:
>
> On Wed, Feb 18, 2015 at 02:48:03PM +0100, malenki wrote:
> > Jochen Topf wrote:
> > 
> > >Please do not add more (and more difficult cases like lakes on
> > >islands in lakes on land) to the data, otherwise this process will get
> > >more brittle than it already is.
> > 
> > Well, that is a word.
> > 
> > What do you think of the Great Lakes mapped (partly) both with
> > coastline and MPs?
>
> The Great Lakes should move away from the natural=coastline mapping. I
> myself have fixed this for some other lakes but didn't want to touch the
> Great Lakes because they are, well, so great, and in parts mapped in a
> lot of detail. I home somebody will take on that project.
>
> Jochen
> -- 
> Jochen Topf  joc...@remote.org  http://www.jochentopf.com/  +49-173-7019282
>
> ___
> 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] New statistics on volume of "note" creation and closing

[Paul Norman]

On 3/3/2015 9:47 AM, Richard Weait wrote:

Are notes more-likely to be resolved when a dialogue is possible
(non-anonymous)?  If the data suggests, for example, that anonymous
notes typically take 3 months to resolve, and non-anonymous notes take
36 hours, perhaps that would be sufficient motivation for a note
author to leave contact information.
Another possible reason is that non-anonymous notes tend to be from more 
experienced users who leave easier to interpret notes. In that case, 
there's not much to be done aside from normal measures to guide people 
to mapping and try to make people return visitors. The solution to 
inexperience is practice.



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

Re: [OSM-talk] Geofabrik routing validator.

[Paul Norman]

On 3/16/2015 11:33 PM, Andrew Errington wrote:
What is the problem?  Is it a data problem or a mistake in the error 
detector?  It could be the access=yes tag (which means access is 
permitted, although it's redundant).
Access=yes for what modes? I'd be surprised if it included 
motor_vehicle, which is what I think the islands are generated for.


___
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

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

[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] 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

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