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

[Paul Norman]

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


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

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

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

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

CJ

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


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


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

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

[Paul Norman]

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


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




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


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

Re: [OSM-talk] Announcement: OpenAirportMap

[Paul Norman]

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


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


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



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

[OSM-talk] OpenStreetMap Carto release v5.7.0

[Paul Norman]

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

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

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v5.6.2...v5.7.0
As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues


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

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

[Paul Norman]

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

Dear OpenStreetMappers,

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



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


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

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

[Paul Norman]

Dear OpenStreetMappers,

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


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


The following services WILL be affected:

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


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


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


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


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

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


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



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

Re: [talk-au] OSM Attribution Q

[Paul Norman via Talk-au]

On 2022-08-14 3:23 a.m., Bob Cameron wrote:

I likely have this wrong, but worth a question.

Looking at petrolspy.com.au website for Theodore Qld and note that the 
sport and rec ground shows a remarkable similarity to the 
changes/updates I did 10 months ago, right down to the service road 
loop around the RV dump. In addition the petrolspy map has copied the 
campsite rather than the reserve name.


There is no attribution I can see, but the site does have Google ads. 
The contact domain (email) is MX'd to Google.



They are using a map from maptiler, which uses OpenStreetMap data. I 
would contact them at the email on their site, explaining that they're 
using a Map based on OpenStreetMap data, and they are required to 
attribute, which is generally done in one of the bottom corners of the map.



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

Re: [talk-au] Multiple web sites linked to car yard

[Paul Norman via Talk-au]

On 2022-07-28 4:22 p.m., Graeme Fitzpatrick wrote:

I saw something similar a little while back when clearing Notes.

Same physical premises had 2 businesses operating out of it, one as 
general scrap metal & the other a car wrecker, but two different 
names, phone numbers & websites.


OK or not?



I could see it for something like that where they're doing somewhat 
different things. I'd say that one is marginal, while in the case linked 
earlier, they were all offering the same service of picking up old vehicles.



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

Re: [talk-au] Multiple web sites linked to car yard

[Paul Norman via Talk-au]

On 2022-07-28 12:29 a.m., nwastra wrote:
This mapper has added about a dozen similar businesses to the same car 
wrecker yard.

https://www.openstreetmap.org/user/freecarpickup/history#map=19/-33.93048/150.99878
I assume this is ok as they are linked to the same physical location.


It's not okay - judging by the imagery and online results, there's only 
one company physically there that does business under multiple names. 
OSM is a map of the world, not a general business directory. There's 
clearly a scrap_yard there, so I've cleaned up the duplicates and left 
the one that was originally mapped. I'll leave a changeset comment on 
one of the mapper's changesets.




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

Re: [talk-au] "Removing closed or illegal trails." (in Nerang National Park)

[Paul Norman via Talk-au]

On 2021-10-28 8:05 p.m., osm.talk...@thorsten.engler.id.au wrote:
If it exists on the ground, it gets mapped. If there is no legal 
access, that's access=no or access=private. If it's a path that has 
been created by traffic where it's not officially meant to go, it's 
informal=yes.



Yep, this is how it is supposed to be handled. Removing paths that exist 
on the ground is vandalism, and counter-productive because the paths 
will be remapped
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-us] Coconino National Forest boundary isn't rendering anymore?

[Paul Norman via Talk-us]

On 2020-07-15 3:00 p.m., Paul White wrote:
Does anybody know why the Coconino National Forest doesn't render on 
osm.org  anymore? I don't see any recent changes that 
would've messed anything up but it's gone. I also noticed that the 
Klamath National Forest is gone, as well.


I assume you're talking about 
https://www.openstreetmap.org/relation/10956348#map=15/35.1483/-111.6705? 
It is rendered - you can see the green outline and text.


https://www.openstreetmap.org/relation/11239975 is a different issue. It 
looks like it might be complex enough that it hits the recursion limits 
of the geometry assembler.


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

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

[Paul Norman via talk]

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


sent from a phone


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

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



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

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

Cheers Martin



Whoops, that should be 128MB.


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

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

[Paul Norman via talk]

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

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

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



The two settings you should adjust are work_mem and maintenance_work_mem.

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


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


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

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


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

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

[Paul Norman via talk]

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

On 19.03.20 02:07, Joseph Eisenberg wrote:

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

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

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

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

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


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


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



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

[OSM-talk] OpenStreetMap Carto release v5.0.0

[Paul Norman via talk]

Dear all,

Today, v5.0.0 of the OpenStreetMap Carto stylesheet (the default
stylesheet on the OSM website) has been released. Once changes are deployed
on the openstreetmap.org it will take couple of days before all tiles
show the new rendering.

Changes include
- An update to Lua tag transforms, setting line vs polygon decisions
  for new tags

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

- Moved MSS files into their own directory

- Removed rendering of power=cable features

- Removed overlay pattern for natural=sand

- Reduced landcover fading at mid-low zoom levels

- Removed rendering of barrier=kerb

Thanks to all the contributors for this release.

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

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


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

[OSM-talk] OpenStreetMap Carto release v4.22.0

[Paul Norman via talk]

Dear all,

Today, v4.22.0 of the OpenStreetMap Carto stylesheet (the default
stylesheet on the OSM website) has been released. Once changes are deployed
on the openstreetmap.org it will take couple of days before all tiles
show the new rendering.

Changes include

- Shop label fixes and use ST_PointOnSurface for building label placement

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

  label placement.

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


- Use retail colour fill on malls

- Drop `highway=steps` from zoom 13

  This makes step rendering consistent with footways

- Render `place=locality` from zoom 16

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

- Render `natural=bay` from linear ways

- Render administrative boundary labels from relations only

- Stop rendering natural=marsh

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


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

  `barrier=city_wall`.

- Support new Tibetan font name

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

- Code cleanups to increase reuse and improve consistency


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

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

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


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

Re: [Talk-us] Request for review of plan for scripted edit

[Paul Norman via Talk-us]

Given the low numbers of 7-digit numbers I recommend correcting them manually rather than writing code to do it.On Aug 8, 2019 2:02 PM, Alex Hennings  wrote:Fixed: references -> relations.Noted: "False impression of data freshness". I hadn't considered this and I would like more opinions.Regarding
 "single area-code Question" I think you're talking about 7 digit 
numbers, and my plan to optimistically appending an area code in cases 
like Maine where there is only one area code. I acknowledge that as the 
weakest of the assumptions but I thought of it as a safe guess and a net
 positive change. For context on why I feel confident, living in Maine 
where we only have one area code, locals will omit the area code 
because we don't need it when dialing locally.Regarding "how many seven-digit numbers" Good question! There are 6 in Maine, 163 in USA.(node    ['phone'~'^([^0-9]*[0-9]){7}[^0-9]*$']    (area:3600063512); // or 3609331155 for usa way    ['phone'~'^([^0-9]*[0-9]){7}[^0-9]*$']    (area:3600063512); relation    ['phone'~'^([^0-9]*[0-9]){7}[^0-9]*$']    (area:3600063512);); out count;The C# tools I'm building should work with any c# IDE. I use VisualStudio which is free, and available on iOS and Windows. I'm happy to help if you want to get them up and running.-Alex

On Thu, Aug 8, 2019 at 3:58 PM Kevin Broderick  wrote:I'm of mixed feelings on the apparent freshness, but as long as the guidelines are followed so changesets are of reasonable size and easily identified as scripted, I don't see much of an issue.While having an automated script make assumptions caused me to twitch a little, the reality is that a human is going to make the same assumption. If I see a seven-digit number on a sign and want to dial it, I'm going to assume that the area code is 207; if I'm across the state line in New Hampshire, I'm going to assume 603. If that assumption isn't correct, the source data is bad anyhow, and adding the implicit area code isn't making it substantially worse. Have you been able to discern how many seven-digit numbers are in the system?On Thu, Aug 8, 2019 at 2:56 PM Jmapb  wrote:On 8/8/2019 1:28 PM, Alex Hennings wrote:
> Community,
>
> I'm planning a scripted change and would like feedback. Plans are
> outlined here:
> https://wiki.openstreetmap.org/wiki/Automated_edits/blackboxlogic
>
> I'd appreciate feedback or questions in the 'Discussion' portion of
> that wiki page, or within this email list.

Hi Alex!

First, a possible typo: I think "Nodes, Ways and References" should be
"Nodes, Ways and Relations"?

I'm a fan of the +1-xxx-xxx- format, since it's the only standard
format that's visually intuitive to North American users. I often switch
numbers to this format when I make updates to an existing POI.

Personally, though, I've always felt a little uneasy about automated
updates like this because they give a false impression of the freshness
of the data. If it's been five years since any "real" updates to a POI,
I'd rather that the date of last update reflected that. It's hard to
gauge the community consensus on this issue, but IMO running this on
POIs that have been manually updated (ie not by a mass edit) in the last
6 months would be fine.

Regarding the single area code question... now that cell phones, VOIP,
and nationwide calling plans are ubiquitous, the idea that a certain
area code refers to a certain area is steadily eroding. I have started
to see a few businesses with out-of-state phone numbers on their
signs... but at this point it's still more likely that an out-of-state
area code is an error or SEO spam. I'd suggest that these would go into
your "Manually review or flag" category.

Regardless, the idea that an area can have a single "traditional" area
code is still true. Personally I have no problem with prepending the
traditional area code onto 7-digit phone numbers. (I do it all the time
in manual mapping.)

Finally, thanks for posting your tools... I see these are written in
CSharp, which I'm only tangentially familiar with. What sort of
environment would one need to build these?

Thanks, Jason



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

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

Re: [Talk-us] What is the meaning of hgv:national_network=yes/terminal_access?

[Paul Norman via Talk-us]

On 2019-08-04 7:56 a.m., Joseph Eisenberg wrote:

I've found this undocumented tag, used 130,000 times, almost
exclusively in the USA.

https://taginfo.openstreetmap.org/keys/hgv%3Anational_network#overview

Values: yes 86.56%   terminal_access 13.37%

I thought it might be imported from Tiger, but the usage has increased
gradually since 2012: 60k more ways have been tagged in that time.


If you look at the length, it increased to 10 km in Nov 2011, and to 
132000 km in Nov 2012. Aside from those sudden increases, there has been 
no change in usage.



How are these tags being used?


They're not.


I'm guessing that hgv:national_network=yes means that a road is
designated for heavy trucks to use for long-distance trips.


It means that it has a particular designation for budget purposes with a 
department of the federal government.


If I'm recalling correctly, these tags were invented by NE2 and never 
subject to any discussion, no data consumers use them, and they are 
poorly documented.


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

Re: [talk-au] Ways to map boundaries that won't go into OSM

[Paul Norman via Talk-au]

On 2019-06-16 10:26 p.m., Ben Kelley wrote:

Hi.

A project I have been thinking about for a while is creating a map of 
Anglican (church) parish boundaries in Australia.


In some sense these are like admin boundaries, but the source of the 
boundary is not easily verifiable. While the resulting map would be 
based on OSM, the data itself probably does not belong in OSM.


Any thoughts on a tool set for how to do this?



I've used uMap (http://umap.openstreetmap.fr/en/) where I want to create 
a map on top of OSM data.



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

Re: [OSM-talk] [Osmf-talk] OSMF Board face-to face meeting: Suggest the topics and issues that matter to you

[Paul Norman]

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

On Thursday 09 May 2019, Dorothea Kazazi wrote:

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

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

Will the answers be published?



We're adding a checkbox to cover that.

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

[OSM-talk] OpenStreetMap Carto release v4.21.0

[Paul Norman via talk]

Dear all,

Today, v4.21.0 of the OpenStreetMap Carto stylesheet (the default
stylesheet on the OSM website) has been released. Once changes are deployed
on the openstreetmap.org it will take couple of days before all tiles
show the new rendering.

Changes include
- Removed unused world_boundaries-spherical.tgz file from scripts

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

- Started using ST_PointOnSurface for some label placements

- Adjusted index for military areas

- Adjusted starting zooms for labeling of administrative areas.

- Revert rendering of healthcare key

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


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

- Only render ferry lines from ways, not relations

- Improved developer internal documentation



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


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

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


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

Re: [Talk-ca] Importing buildings in Canada

[Paul Norman via Talk-ca]

The sources of the data are different in different regions, as well as the existing communities. A Canada-wide process won't work when each import is going to vary.On Apr 27, 2019 1:40 PM, john whelan  wrote:We now have three sources of data with the correct licensing.I'm proposing that I amend both the import plan and the import mailing list to include the three alternative sources.I'm tempted by the idea of splitting the country up into regions of some sort.We have a couple of groups currently who I think would like to import what is available in Alberta and Manitoba.  Are we asking them to hold off until Pierre and company have come up with a cleansing routine?Thoughts ladies and gentlemen please.Thanks John
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [OSM-talk] iD influencing tagging

[Paul Norman via talk]

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

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

Re: [Talk-us] US map rendering (Was: Re: Spot elevations collected as natural=peak and name=Point (height in feet))

[Paul Norman via Talk-us]

As a maintainer of some of the projects listed, I find that you're 
misrepresenting the situation.


On 2019-03-08 11:25 a.m., Kevin Kenny wrote:

I've sounded out the maintainers of various of the OSM software, and
get different assessments.
osm2pgsql - Actively hostile to supporting what I need, contend that
osm2pgsql is the wrong tool for the job.


This is incorrect. Both maintainers have interest in adding 
functionality for propagating information from relations to ways - as 
opposed to from ways to relations, which is already supported. Neither 
of us have the free time to code it. If someone wanted to take this on, 
we'd help with the related issues like Lua API changes.



OSM Carto - Little interest, but that's because of the emphasis on
consistent rendering worldwide, and this is really a project specific
to North America.


Pictorial road shields require rendering ref from route relations, and 
that is not an easy problem to solve. I'm on record as doubting it can 
be solved given the technical and cartographic constraints the style 
faces. Allowing propagation of information from relations to ways would 
change that.


It sucks to hear that it won't be implemented without someone stepping 
forward with pull requests, but that's the reality of the situation.



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

Re: [Talk-ca] Building Import

[Paul Norman via Talk-ca]

On 2019-03-15 9:07 a.m., Andrew Lester wrote:

I disagree. Silence won't solve anything.

I'm speaking here as a local BC mapper, and I strongly disagree with 
these recent imports.


I'm also a BC mapper, and have only seen the consultation happen over 
Ontario, not BC.



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

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

[Paul Norman via talk]

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


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


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



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


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



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

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

[Paul Norman via talk]

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

Hi,

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

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



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



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

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

[Paul Norman]

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

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



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

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



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

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

[Paul Norman]

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

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



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



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

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

[Paul Norman]

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



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



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

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

[Paul Norman]

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

What do you think?


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


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


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


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

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

[Paul Norman]

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

> It is a CanVec import from 4 years ago

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


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


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


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

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

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

[Paul Norman]

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



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




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

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


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


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

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

[Paul Norman]

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


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



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



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




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


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


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


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


A less wrong way would be to modify your filtering so no nodes are 
filtered out. There are still potential errors with relations, but these 
are less common. If you're doing the planet or a large extract and using 
flat nodes there's no storage penalty for having all the nodes.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Paul Norman]

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

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

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


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


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

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

[Paul Norman]

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


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


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


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


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

Re: [Talk-GB] Closed software supplier ESRI creates OSM vector tile basemap

[Paul Norman]

On 2018-07-10 2:00 PM, Mark Goodge wrote:
ESRI's free maps can be accessed as server-side tiles. See 
Leaflet-providers for some examples:


https://leaflet-extras.github.io/leaflet-providers/preview/

I'm not sure of the licence restrictions which apply to them, or any 
rate limits. But, from a technical point of view, it's just as easy to 
use as OSM Carto tiles. 


The ESRI layers listed on leaflet-providers are from a different host, 
and looking at URLs, I wasn't able to get raster tiles from the new 
vector basemap.


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

Re: [Talk-GB] Closed software supplier ESRI creates OSM vector tile basemap

[Paul Norman]

On 2018-07-10 12:30 PM, Mark Goodge wrote:


I think it's a positive. One of the biggest issues with large-scale 
use of OSM is that OSM's own tile server isn't suited for high-volume 
use, but most of the alternative tile servers are rate-limited and 
require payment for larger volumes. If ESRI's tile server will, as the 
blog post suggests, be free to access, then it will be a more useful 
alternative for users who don't have the resources to host their own 
tile server.


It's not the same as OpenStreetMap Carto. OpenStreetMap Carto is written 
in CartoCSS and rendered server-side, what they have uses client-side 
rendering and lots of ESRI technology.


I think a more granular update schedule is unlikely to be an issue for 
most users. Even "every few weeks" is going to be a lot better than 
Bing and Google.


Yes, every few weeks is more than fast enough for most uses. osm.org is 
different because it's part of the feedback cycle, so minutely updates 
matter. Quarterly updates are common with many maps.


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

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

[Paul Norman]

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




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


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


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


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

[OSM-talk] OpenStreetMap Carto release v4.12.1

[Paul Norman]

Dear all,

Today, v4.12.1 of the OpenStreetMap Carto stylesheet (the default
stylesheet on the OSM website) has been released. Once changes are deployed
on the openstreetmap.org it will take couple of days before all tiles
show the new rendering.

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

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


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


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

Re: [OSM-talk] OpenStreetMap Carto design

[Paul Norman]

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

So what is intended to replace CartoCSS? Vector tiles?


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


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

Re: [OSM-talk] OpenStreetMap Carto design

[Paul Norman]

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



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

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


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


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


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

[Talk-ca] Terminating British Columbia Mosaic imagery

[Paul Norman]

I will be shutting down the "British Columbia Mosaic" imagery in the 
near or medium future. I set this up in about 2011, and the system has 
been running without many updates since then.


When I started hosting it, we had access to Bing and Yahoo. Between the 
two of them, we had acceptable for the time imagery in Vancouver, and 
poor imagery in Burnaby and east. Living in New West, this was a problem 
for me, so I put together the layer. My main sources were 10cm 2009 
imagery covering Vancouver, 2009 20cm imagery for Burnaby, 2011-2012 
10cm and 40cm for Surrey, and a few other minor sources.


The accuracy and colour range of the Surrey imagery was exceptional for 
the time, and remains exceptional by today's standards. The accuracy of 
other sources was also good, but colours weren't the best. This allowed 
an imagery layer that could be assumed to have accurate positions 
without checking GPS traces everywhere, and its accuracy was ahead of 
the data in OSM at the time, as well as being recent enough.


Times have changed, and we have more imagery hosts. In particular, we 
normally have commercial imagery hosts who will host the open imagery 
that is available, and handle any legal matters about its usage. I 
remember trying to get Bing, Mapbox, or anyone to use the Surrey imagery 
in Surrey, which was better than what they were using in every way and 
free, and having no luck. The data in OSM is frequently more recent than 
the imagery.


Before deciding to shut it down, I reviewed the available imagery in a 
few areas, and recommend defaulting to ESRI imagery in all of the Lower 
Mainland, with the exception of some cloudy parts of Ladner.* In Ladner, 
and if slightly more recent imagery is needed elsewhere, I recommend 
DigitalGlobe Standard Imagery as a lower quality but more recent source. 
Both have excellent alignment. I would not recommend Mapbox Satellite or 
Bing anywhere in the region.


Instead of shutting down, why am I not moving it to a different server? 
Time, mostly. With all of the sources I had used out of date, I'd have 
to find new ones. This would take a lot of time to find and process 
sources, and a lot of time to sort out the legal mess that is open data 
in Canada. I would also probably take a different approach, with 
multiple independent layers that the editor software picks between.


I believe there is still a place for user-hosted imagery, but at least 
here, it will never offer such an increase in quality again, because the 
commercial hosts are offering a much better "baseline".


* Alignment in Hope was possibly worse, but I haven't done extensive 
research into the accuracy of BC Mosaic in that region. I couldn't find 
any good objects to compare with in Whistler, I kept finding stuff had 
changed on the ground, which is a good reason in itself to avoid BC Mosaic.



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

Re: [Talk-us] Slack: Do we need an Alternative (was Planning an import in Price George...)

[Paul Norman]

On 2018-06-09 1:19 AM, Frederik Ramm wrote:

Apart from the reasons you mentioned, having a record is also an
important factor. Anything that has gone on on these mailing lists is
practically archived forever and for all to see


This is also a good reason to ask questions on something other than 
Slack, if someone else might have the same question. A question on 
help.osm.org, an issue tracker, stackexchange, mailing lists, forums or, 
something else publicly archived can be found in the future by someone 
who has a similar question in the future.


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

Re: [OSM-legal-talk] License clarification

[Paul Norman]

On 2018-06-07 12:19 AM, Christoph Hormann wrote:

The idea that you can produce a data set using both OSM and non-OSM data
in a meaningful way without there being either a collective or a
derivative database seems fundamentally at odds with the basic concept
of the ODbL.  The only way this could fly from my point of view would
be if you could argue the use of OSM data is insubstantial - for which
i see no basis in either law or the Substantial Guideline:


There's another case - when it isn't part of a collection of independent 
databases or doesn't have an alteration of OSM data, but it's just OSM 
data unmodified. This is the "this database" part of 4.2, talking about 
"this Database, any Derivative
Database, or the Database as part of a Collective Database." 4.2 doesn't 
talk about the fourth case, which is is insubstantial, where the law 
either provides no database (or similar) rights, or the ODbL waives them.


___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-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: [Diversity-talk] Idea: Quarterly Projects for a traditionally underrepresented topic(s)/groups?

[Paul Norman]

On 3/26/2018 1:24 PM, Rory McCann wrote:

Any ideas for topics?


Some ideas

- Regional languages. Is there a regional language you speak? Make sure 
that you're adding it to the map when objects have a name in that 
language. Unfortunately, this isn't great for a global project because 
not everyone can do it.


- Traditionally "blue-collar" areas. It's fairly well known that these 
are underrepresented in OSM, and there's a lot of mapping that can be 
done remotely. Something I've worked on has been mapping industrial 
parks. For these, a basic mapping would be buildings, industrial area 
names, building numbers, landuse, and service roads on them. Many 
industrial parks have places to eat to serve the workers around them and 
these are important to map too. There's lots more that could be mapped, 
but this would be a good start.


- Wheelchair access has lots of resources, but isn't underrepresented in 
OSM mapping.


___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org

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

[Paul Norman]

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


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


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


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


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

Re: [Diversity-talk] Who Maps The World

[Paul Norman]

On 3/18/2018 3:23 PM, Charlotte Wolter wrote:

Paul,

A kindergarten is a school, not a child-care center. They are two 
fundamentally different things. Also, child-care centers serve a range 
of ages, not just 5-year-olds. I, too, tried to find a real child-care 
tag a few months ago. There is none, and "kindergarten" doesn't cut it.


In American English kindergarten has this meaning, but 
amenity=kindergarten is used for "Use the amenity=kindergarten for 
establishments offering early years education and supervision (also 
known as pre-schools) for children up to the age of formal (often 
mandatory) school education. This tag is also currently used for 
establishments where parents can leave their young children but which 
provide no formal education."


When we get to specific uses, it is used for "a day facility for 
children, covering a wider and overlapping range of crèche children (0-3 
years), kindergarten/preschool (3-6 years), and after-school care for 
primary school children (6-12 years)"


I was looking for child-care a few months ago, and the places that I 
found that were also in OSM were mapped with amenity=kindergarten.


Don't worry too much about the meaning of OSM tags in American English. 
They're supposed to be defined in British English, and even then, the 
meaning can shift as people use it, just like language can.
___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org

Re: [Diversity-talk] Who Maps The World

[Paul Norman]

On 3/14/2018 6:47 PM, alyssa wright wrote:

Hi all,

City Lab article below on gender disparity in OSM. I actually think 
things have evolved and are more nuanced then ever before. Wondering 
if I am being naive.


Yes - part of the thesis of the article is based around the claims of 
what gets mapped. The claims in the article do not reflect reality.


OSM has more childcare centers (amenity=kindergarten) mapped than sports 
arenas or sports arenas, the examples from the article. I couldn't 
figure out what tags Levine was talking about for strip clubs.





For healthcare, the claims are vaguer, but as a general rule, "primary" 
information like something being a doctor's office, clinic, or other 
healthcare facility gets mapped faster than "subtag" information like 
what type of specialty the doctor's has. This is normal - when I'm out 
mapping, noting where there's a doctor's or clinic is more important 
than what type it is. You see the same in other subtags.


 Looking at what healthcare facilities is tagged with that additional 
information, and ignoring "general", the five most popular are 
"Obstetrics and gynaecology", "Ophthalmology", "General (internal) 
medicine", "Paediatrics", and "Trauma and orthopaedic surgery". (UK terms).


The gender percentages are interesting, and if accurate, put a much 
lower value on percentage of mapping that HOT does than I've seen in the 
past. I suspect there are some problems with different sources of 
numbers, and the numbers cited not being accurate.


[1]: https://taginfo.openstreetmap.org/keys/healthcare%3Aspeciality#values
___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org

Re: [Talk-GB] Petrol stations again

[Paul Norman]

On 3/8/2018 1:28 PM, SK53 wrote:
Remarks about individual items to be added which I have examined 
(mainly, I thin, for Ilya's benefit):


Were the 8 errors from the full set of 400, or a subsample of them?

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

Re: [Talk-us] Help fight advertising

[Paul Norman]

On 3/2/2018 9:40 AM, Clifford Snow wrote:
Sorry for the late posting - I've been working on another project for 
the past few days.


Frederik wrote "You will be surprised about the breadth of marketing 
blurb that has already crept into OSM."


Unfortunately no, I'm not surprised. Marketing is a very competitive 
world. SEO firms are using every trick in the dictionary to improve 
their page ranking.


True, those experienced with SEO firms are probably not surprised.

One of my beliefs from looking at SEO spam is that I believe the work 
is likely being outsourced. Two many similarities exist that to me 
suggest these are coming from a common source.  The user name, the 
changeset comments, etc. I did ask Margaret Seksinski with Brandity if 
she could help us learn who might be behind this spam. I have yet to 
hear from her. Unfortunately, it appears Brandify doesn't want to be a 
part of the community, just use us for their gains.


With my DWG hat on I've seen some investigations into some cases. Much 
of what I've seen comes from a number of overseas sources, and there's 
probably a disconnect between the firms people pay and who spams the data.




Frederik suggested we contact the user. I've sent numerous message and 
have not only not had any response, but have yet to see any change in 
their behavior. Frankly it's a waste of my time anymore to attempt to 
contact them.


As much as I hate the spam in the description tag (should rename it 
spam=*) it is helpful in attempting to determine the correct tags. 
After which, it's no longer useful and can be deleted.


At this point I generally don't do that, I end up deleting the spam. 
With the location frequently sourced from Google's geocoder, it's 
unusable, many of the businesses don't have physical locations and don't 
belong in OSM, and the users are consistently uncommunicative.


Finally let's not lump all SEO firms together. The Laua Group is doing 
a great job for Hilton Hotels. We should encourage more firms to be 
good community members.


There are some reputable SEO firms. Unfortunately, the industry tends to 
attract disreputable ones. The disreputable ones are unlikely to follow 
rules. Remember, this is an industry where disreputable companies still 
flood comments sections, user profiles, and anything else they can 
imagine with spam. If they're fine with breaking anti-spam laws, terms 
of service, and other rules, I can't see them following either OSMF 
policies or community expectations, so we shouldn't gear our work around 
them doing that.


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

Re: [Diversity-talk] Code of Conduct & Moderation for this list

[Paul Norman]

On 2/28/2018 2:44 AM, Rory McCann wrote:

Hi all,

To follow up on the phone call, and waiting a little bit for people to
join. 

I think this list should have a Code of Conduct. I propose something
like Geek Feminism's one. Thoughts?

http://geekfeminism.wikia.com/wiki/Community_anti-harassment/Policy


I see nothing wrong with a mailing list deciding on rules for how they 
moderate themselves. Before setting rules, it's important to identify 
what behavior is an issue. With OpenStreetMap Carto's (osm-carto) Code 
of Conduct, I wanted to start with text that covered derailing topics, 
including by taking issues off-topic. osm-carto went with a CoC based on 
that of Go.[1]


The other codes of conduct that made my list for consideration were 
those from Debian, FreeBSD, Go, Joomla, Puppet, GNOME, Julia, and KDE. A 
downside to this list is that they're all software development related 
projects. OpenStreetMap Carto is similar to one[2], but OpenStreetMap 
isn't a software project. I would want to also consider what other 
non-software volunteer groups are doing. Some that kind to mine are 
cycling associations, ramblers, and other groups which OSM has a strong 
tie to.


A couple of issues I would consider if I were doing the selection again 
are readability and education or socioeconomic status. Readability is a 
big problem with many codes of conduct. The Go CoC comes with a score of 
11-13,[3] and I'd want 8-10 at most. This is better than the Geek 
Feminism one, which scores 13-15 and uses a lot of jargon.


For education and socioeconomic status, I can't say it any better than 
Richard Fairhurst did [4]:


Volunteer communities in general, and open source software in 
particular, can be unwelcoming places for people from poorer 
backgrounds or without a university/college education. Wealthy, 
educated people - which most open source contributors are - can easily 
dismiss contributions from such users through rhetorical skill, 
through sniping on grammar/spelling etc., and through belitting their 
concerns as not representative of the empowered, educated group.


Increasingly I have noticed that contributors from these [areas where 
residents have typically benefited from as good an education, and have 
less well-paying jobs] find it hard to articulate their views on the 
site without being shot down by the wealthier, more educated majority. 
This might take the form of the majority criticising minority 
contributors over minutiae (small sincerely-believed factual 
inaccuracies, grammar/spelling); or a deliberate unwillingness to 
tolerate assumptions that differ from the majority; or constructing 
means of engagement/consultation that are less open to those from 
poorer backgrounds (evening meetings arranged which are effectively 
closed to those unable to get childcare, etc.).


My open-source background is largely in the OpenStreetMap project 
where there has been a fair amount of academic research done into 
contributor biases (particularly, though not entirely, through the 
work of Professor Muki Haklay). The result of such bias is easy to 
visualise in OSM: wealthy areas such as London or San Francisco are 
mapped in much more detail than poorer areas such as the Welsh Valleys 
or the rural American Midwest. However, although the prevailing 
open-source narrative has led to a fair amount of (welcome) discussion 
as to how we can welcome and help those groups traditionally 
considered marginalised in technology, there has been little or no 
thought given to how we make ourselves more welcoming to poorer or 
less well educated people. Indeed, there are instances of where such 
contributors have received a hostile reception on the project's 
communication channels (mailing lists, on-site discussions).



[1]: The reporting mechanisms weren't suitable for a small project
[2]: It's style development, but we communicate over issues, pull 
requests, and similar means.
[3]: Sometimes called grade level, but that leads people to bad 
assumptions about what level of education is needed to understand a 
piece of text

[4]: https://github.com/ContributorCovenant/contributor_covenant/pull/491

___
Diversity-talk mailing list
Code of Conduct: TBD
Contact the mods (private): diversity-talk-ow...@openstreetmap.org
(_internal_name)s

Re: [Talk-us] Satus CDP

[Paul Norman]

On 2/26/2018 4:59 PM, Clifford Snow wrote:
In the middle of the Yakama Nation Indian Reservation sits Satus [1] 
that as far as I know only exists in some Census bureaucrat world. 
Asking around here I haven't found anyone familiar with the area. 
Wikipedia [2] doesn't help much either.


I'd like to remove it from OSM. What reasonable checks do I need to do 
before deleting it.


It sounds like you've done them.


Or do they belong in OSM and I should leave it alone.


CDPs don't belong in OSM for their own sake.* In some cases, a CDP 
corresponds to a real place, and they're useful then. In other cases, 
they have no relation to the situation on the ground, and shouldn't be 
in OSM.


* Leaving aside Alaska, which has an administrative structure different 
than the rest of the US.


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

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

[Paul Norman]

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

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

(ignore what the article is about)


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



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





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


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

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

[Paul Norman]

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


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


I could think of the following three approaches so far:

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


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


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


What else, if anything, could be done? 


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


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


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


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

Re: [OSM-legal-talk] Interesting use case of combining OSM with proprietary data

[Paul Norman]

On 1/11/2018 7:30 AM, Christoph Hormann wrote:

My interpretation of the ODbL here is that this is a share-alike case
that would require the combined data sources to be made available.  But
you could probably also look at it differently.  I would like to hear
opinions on this.  In particular if you think that is legally possible
without share alike how this interpretation looks like.


Has anyone requested the derivative database their produced work is 
based on? It'd give us their interpretation.


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

Re: [Talk-us] Leonia, NJ doesn't want you to navigate through

[Paul Norman]

On 1/8/2018 10:53 AM, Jack Burke wrote:
I'll leave it to others to decide what, if anything, we should do 
about this.


http://newyork.cbslocal.com/2018/01/05/leonia-streets-off-navigational-apps/


If they actually go through with it, access=destination on the 
applicable streets, or motor_vehicle=destination if it's motor vehicles 
only.


I think what they're doing is a bad idea and unlikely to achieve their 
stated goals, but that's a problem of the city, not us. We just need to 
map what they do accurately.


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

Re: [Talk-GB] Importing Shell fuel stations

[Paul Norman]

On 11/3/2017 10:51 AM, Ilya Zverev wrote:

Philip, the shell.co.uk website gives the same opening hours for the Branting 
Hill station as the source dataset. Basically, everything in the dataset is the 
same, except for locations, which have been improved by the Navads team.


What percentage of the opening hours in Shell's dataset do you estimate 
are wrong?


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

Re: [Talk-in] How to get a bot account to upload translated strings for OSM?

[Paul Norman]

Are you generating strings for the software which runs 
openstreetmap.org, or translating place names in OpenStreetMap data? If 
the latter, you shouldn't upload them. The name:* tags in OSM are for 
names in different languages, not for translations of names to different 
languages.



On 10/17/2017 1:08 AM, Shrinivasan T wrote:

We are working on a TelegramBOT to translate strings for OSM.

Last saturday, we released and demonstrated a telegram bot  
'osm_tamil' to translate strings for openstrertmaps.org 
 at ilugc meet.



Here is a quick walk through video in Tamil.

https://youtube.com/watch?v=dJkeRKuu1F8 




Source code is here
https://github.com/Dineshkarthik/OSM-Translate-TelegramBot 



Explore this and share your thoughts.


Once the strings got translated by volunteers, hope we can use a bot 
account to upload the works.


How to apply and get a bot account for OSM?

Thanks.


--
Regards,
T.Shrinivasan


My Life with GNU/Linux : http://goinggnu.wordpress.com
Free E-Magazine on Free Open Source Software in Tamil : http://kaniyam.com

Get Free Tamil Ebooks for Android, iOS, Kindle, Computer : 
http://FreeTamilEbooks.com



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


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

Re: [Talk-us] Texas - redacted roads.

[Paul Norman]

On 10/12/2017 6:54 PM, Nick Hocking wrote:


Should we (in OSM) put what the user will probably search for, the 
correect (hypothetically) Redwil or should we put the "ground truth" 
(REED WILL) which is what the user will see if he acually ever makes 
it to that location.


Although this has been resolved as a misreading of the site, in this 
case, correct is the ground truth.


For OSM, the data from the city is not authoritative. Ground truth is.

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

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

[Paul Norman]

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


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


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

[OSM-talk] DWG survey on organised editing

[Paul Norman]

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

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

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

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

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

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

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

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

--
Paul Norman
For the OSM Data Working Group


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

[OSM-talk] OpenStreetMap Carto release v4.3.0

[Paul Norman]

Dear all,

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

Changes include

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

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

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

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


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

Re: [Talk-us] guidelines regarding roads access

[Paul Norman]

On 9/14/2017 12:23 AM, David Wisbey wrote:


I limit the use of "residential" to typical residential city or town 
government-maintained streets.


I use "living street" for residential streets that are completely open 
to the public but not maintained


by the local or state government; they must have a street name as well.

I use "service road" (with no service road type added) for the main 
ways through and around


a development (mobile home park, apartment complex, condominium or 
townhome cluster, etc)


that do not have names of their own. If they do have have names, I map 
those that have the names


as "living street".



This is incorrect use of highway=living_street. With some rare 
exceptions, highway=living_street do not exist in the US or Canada, and 
the concept does not generally exist in our traffic codes.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

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

[Paul Norman]

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


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


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


Paul Norman
For the OSMF Data Working Group

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

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

[Paul Norman]

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


What makes you believe this to be so?

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

Re: [Talk-us] natural=* and landuse=* multipolygons at the urban interface

[Paul Norman]

On 8/13/2017 4:34 PM, Steve Friedl wrote:

You’re right that splitting this up is the right approach, because I don’t 
believe having all this as one huge relation was every the right thing to do as 
I cannot see how the related-ness of all the scrub patches in a very wide area 
is useful information (the scrubs that are part of the relation are not any 
more “related” than standalone patches of scrub in the same area).


I've cleaned up a few areas. Generally I end up deleting most of the 
imported data, as it's wrong as often as it right and impossible to work 
with.


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

[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: [Talk-GB] Birmingham Tree Import

[Paul Norman]

On 4/27/2017 12:26 PM, Brian Prangle wrote:
Apart from some posts  about the problems with email notifications of 
changeset discussions, there has been nothing to indicate where I take 
this import. I guess that's because the initative is really down to me.


I've annotated Harry's Import wiki page 
 
with some comments and ideas. I've copied below what I think are the 
relevant bits from the wiki page and I look forward to resolving the 
issues as I'm keen to complete the import.


Don't forget the need to consult with imports@ as part of the 
consultation with the community.
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[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

[Talk-GB] Local chapter application by OpenStreetMap United Kingdom

[Paul Norman]

The OSMF has received an application from OpenStreetMap United Kingdom
(OSM UK) for their organization to become the OSMF local chapter for the
United Kingdom (including the Isle of Man and Channel Islands). For
consultation and as part of due diligence we are asking the UK community
for comments on the application. Because there is not just one mailing
list for the region, this is being sent to talk-gb@, talk-scotland@, and
talk-ie@. If you are aware of other communication channels the UK local
community uses, please let them or me know.

If you wish to raise concerns about the application privately, you can
do so by emailing me.

Details of the application can be found at
http://wiki.osmfoundation.org/wiki/Local_Chapters/Applications/United_Kingdom
and the standard template agreement that would be signed is at
http://www.osmfoundation.org/wiki/Local_Chapters/Template_agreement.

More information on local chapters can be found at
http://www.osmfoundation.org/wiki/Local_Chapters/FAQ

Paul Norman
OpenStreetMap Foundation

Name & Registered Office:
Openstreetmap Foundation
132 Maney Hill Road
Sutton Coldfield
B72 1JU
United Kingdom
A company limited by guarantee, registered in England and Wales.
Registration No. 05912761.


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

[OSM-talk-ie] Local chapter application by OpenStreetMap United Kingdom

[Paul Norman]

The OSMF has received an application from OpenStreetMap United Kingdom
(OSM UK) for their organization to become the OSMF local chapter for the
United Kingdom (including the Isle of Man and Channel Islands). This
includes Northern Ireland but not the Republic of Ireland. For
consultation and as part of due diligence we are asking the UK community
for comments on the application. Because there is not just one mailing
list for the region, this is being sent to talk-gb@, talk-scotland@, and
talk-ie@. If you are aware of other communication channels the UK local
community uses, please let them or me know.

If you wish to raise concerns about the application privately, you can
do so by emailing me.

Details of the application can be found at
http://wiki.osmfoundation.org/wiki/Local_Chapters/Applications/United_Kingdom
and the standard template agreement that would be signed is at
http://www.osmfoundation.org/wiki/Local_Chapters/Template_agreement.

More information on local chapters can be found at
http://www.osmfoundation.org/wiki/Local_Chapters/FAQ

Paul Norman
OpenStreetMap Foundation

Name & Registered Office:
Openstreetmap Foundation
132 Maney Hill Road
Sutton Coldfield
B72 1JU
United Kingdom
A company limited by guarantee, registered in England and Wales.
Registration No. 05912761.


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

Re: [Talk-in] license compatibility of various data sources for india

[Paul Norman]

On 4/5/2017 9:50 PM, Srihari Thalla wrote:

But DataMeet has only 5 states :-/

What about this repo - 
https://github.com/justinelliotmeyers/official_india_2011_village_boundary_lines

Does it contain all of them?


There doesn't seem to be any license there, so they're unusable without 
that.


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

Re: [Talk-in] How to get all missing street names for chennai?

[Paul Norman]

On 4/3/2017 12:25 AM, Srikanth Lakshmanan wrote:
Offlate, I am facing strange unicode issues with my script which used 
to work, but will soon get it fixed. I am thinking of trying 
TensorFlow or equivalent ML models to provide translation suggestions, 
aside from google translate. Wikidata doesnt help when it comes to 
street level sadly.


I'd stay away from translation. name:* tags are for names in different 
languages, not translations of names.


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

Re: [Talk-us] Sabotage or a really bad bot?

[Paul Norman]

On 4/2/2017 6:26 PM, Charlotte Wolter wrote:


I came across a really weird situation while doing a 
Maproulette change.
In Rustberg, a small town in rural Virginia 
(http://www.openstreetmap.org/edit?editor=id#map=16/37.2772/-79.1011), 
almost every driveway has been named after the street it intersects. 
In addition, numerous very short "driveways" have been created, some 
of which go nowhere.
The edits all were done four years ago, it seems. Here is the 
message about the edits: "Edited almost 4 years ago by bot-mode
Version #2 · Changeset #15805152." 



They were created 9 years ago with the TIGER import: 
http://www.openstreetmap.org/way/19903814/history. The change 4 years 
ago was just a name change and not related to what you're observing.


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

[Talk-ca] Vancouver mappy hour

[Paul Norman]

Starting this year, we're aiming to have monthly mappy hours in 
Vancouver, on the 4th Friday of each month. The next one is Friday March 
24th, near Metrotown at 6:30 PM at the Firefighters' Public House. This 
is convenient to transit


Full details are at 
https://www.meetup.com/OpenStreetMap-Vancouver/events/237996240/, and 
the events are also on the calendar on the wiki.




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

Re: [Talk-ko] Use of questionable imagery in Korea

[Paul Norman]

On 2/25/2017 2:47 AM, Paul Norman wrote:

On 2/23/2017 12:00 PM, Simon Poole wrote:
while not speaking for the DWG, I suspect that due to the touchy 
nature of this specific source we will want to redact the edits 
(which removes them from history too) so likely it doesn't make sense 
to revert them manually. As the changesets in question are easy to 
identify this should not be a larger problem.


Unfortunately, this is correct. It looks like it'll be 133 users and 
2257 changesets. I'm planning to leave messages in changeset 
discussions on their most recent changesets. 


Just a quick update: I have left the message and translation by 최규성 on 
the changeset discussions and begun the redactions. I estimate it will 
take over two weeks to redact everything.
___
Talk-ko mailing list
Talk-ko@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ko

Re: [Talk-ko] Use of questionable imagery in Korea

[Paul Norman]

On 2/23/2017 12:00 PM, Simon Poole wrote:
while not speaking for the DWG, I suspect that due to the touchy 
nature of this specific source we will want to redact the edits (which 
removes them from history too) so likely it doesn't make sense to 
revert them manually. As the changesets in question are easy to 
identify this should not be a larger problem.


Unfortunately, this is correct. It looks like it'll be 133 users and 
2257 changesets. I'm planning to leave messages in changeset discussions 
on their most recent changesets.


Could someone translate this to Korean for me?

Hello,

In OpenStreetMap you can't copy from copyrighted maps without 
permission. This includes vworld, which you did here. Continuing to copy 
like this could lead to a permanent block. Unfortunately I have to 
remove this copied data.


Paul Norman
For the OpenStreetMap Data Working Group

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

Re: [OSM-talk] Fixing broken multipolygons

[Paul Norman]

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


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


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

Re: [OSM-talk] Fixing broken multipolygons

[Paul Norman]

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

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

https://osmium.osm2pgsql.paulnorman.ca

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


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


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

[OSM-talk] OpenStreetMap Carto database schema change

[Paul Norman]

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


- database schema change;

- disjoint area handling;

- different tag columns; and

- multipolygon handling changes

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


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



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

[OSM-talk] OpenStreetMap Carto release v3.1.0

[Paul Norman]

Dear all,

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

Changes include

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

Thanks to all the contributors for this release.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v3.0.1...v3.1.0

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


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

Re: [Talk-us] U.S.-Mexico border fence update

[Paul Norman]

On 1/24/2017 11:24 AM, Michael Corey wrote:

Thanks, folks, these are good suggestions. I think posting the map in
Github is a good first step -- we first have to iron our our licensing
so it's compatible with OSM and with our own licenses.


Just to note, if it's based on the OSM border data, it's automatically 
ODbL and compatible with OSM, so there should be no problems there.


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

Re: [Talk-ca] Crowdsourcing buildings with Statistics Canada

[Paul Norman]

On 1/21/2017 3:11 PM, Paul Norman wrote:

On 1/20/2017 5:33 PM, john whelan wrote:
Did you include permission for the bus stops as well? They are from 
the same source and the same licence.  I think I might have included 
one pitch sport soccer.  The pitch was mapped but the sport soccer 
was I must confess taken from their open data source.


I kept it generic, not specifying a particular dataset. That way we'll 
have a final answer one way or the other and won't have to go back to 
them all the time. 


The initial answer was that the license would impose obligations on top 
of the ODbL, our distribution license. This would make the data 
incompatible.


I have gotten back to them with some additional questions which might 
offer a way forwards and clarify the problems. If I can't get anywhere 
we'll have to decide what to do, but it will probably mean we can write 
off the City of Ottawa as a potential data source.
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Crowdsourcing buildings with Statistics Canada

[Paul Norman]

On 1/22/2017 9:06 AM, James wrote:
So if I understand correctly Paul, CC0 or any other license would 
require permission as a bypass to the license, even though it would be 
considered compatible with ODBL.


No. CC0 is compatible with the ODbL, so you can just go ahead and use 
the data*, subject to any conditions the community has developed around 
imports.


* There could be exceptional circumstances in some cases.

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

Re: [Talk-ca] Crowdsourcing buildings with Statistics Canada

[Paul Norman]

On 1/22/2017 9:48 AM, James wrote:
So why is this not considered the exact same as OGL-CA, which is 
considered compatible with ODBL?




As mentioned previously, the OGL-CA is compatible because the Federal 
government has said so for their data. The Federal government's 
statement only applies to their data under their license.


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

Re: [Talk-ca] Crowdsourcing buildings with Statistics Canada

[Paul Norman]

On 1/22/2017 7:07 AM, John Marshall wrote:

Paul,

So once we get a letter from the City of Ottawa, are we good to add 
the buildings as per the wiki?


It depends what they say in their reply. If they say no, then we can't 
use their data. If we have a suitable reply, then we are able to legally 
use their data.


There are of course other requirements that the community has developed 
like documenting the import, etc, and the letter has nothing to do with 
these.


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

Re: [Talk-ca] Crowdsourcing buildings with Statistics Canada

[Paul Norman]

On 1/21/2017 4:34 PM, john whelan wrote:
What you have is an interpretation of the Federal Government license.  
From my background in the civil service my understanding is for a 
statement it would have to be over a minister's signature or by act of 
parliament.  No one else has the authority unless it is delegated.


If that's true and we can't rely on a statement from a government 
employee to interpret their license, then we can no longer use OGL-CA data.


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

Re: [Talk-ca] Crowdsourcing buildings with Statistics Canada

[Paul Norman]

On 1/21/2017 3:48 PM, James wrote:
It is, the thing they changed was federal references to municipal 
ones. Which is why i'm confused the license is "not compatible"




We have a statement from the Federal government for their data under 
their license. The Federal government cannot make a statement about City 
of Ottawa data under the City of Ottawa license.
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Crowdsourcing buildings with Statistics Canada

[Paul Norman]

On 1/20/2017 5:33 PM, john whelan wrote:
Did you include permission for the bus stops as well? They are from 
the same source and the same licence.  I think I might have included 
one pitch sport soccer.  The pitch was mapped but the sport soccer was 
I must confess taken from their open data source.


I kept it generic, not specifying a particular dataset. That way we'll 
have a final answer one way or the other and won't have to go back to 
them all the time.


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

Re: [Talk-ca] Crowdsourcing buildings with Statistics Canada

[Paul Norman]

On 1/20/2017 3:22 PM, James wrote:

Old link to an old wiki. Please see:
https://wiki.openstreetmap.org/wiki/Canada:Ontario:Ottawa/Import/Plan#Permission

That says Ottawa gave some data to Stats Canada in 2016, not that their 
data can be reused under the ODbL. I've sent an email to them asking for 
permission. We need this because we're getting the data directly from them.
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Crowdsourcing buildings with Statistics Canada

[Paul Norman]

On 1/20/2017 12:40 PM, Ellefsen, Bjenk (STATCAN) wrote:


Hello everyone,

Big news, the City of Ottawa has released the footprint of over 
325,000 buildings on their open data portal in support to the project 
with Statistics Canada and the OSM community.


We are very grateful for the amazing collaboration with the City of 
Ottawa on this pilot project and are very pleased for this amazing 
contribution.


Link:

http://data.ottawa.ca/en/dataset/urban-buildings



Is there a statement anywhere from Ottawa saying that their license is 
compatible with the ODbL? All I can find is 
https://wiki.openstreetmap.org/wiki/Canada:Ontario:Ottawa/Import/Permission 
which seems to be about their previous license.
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] [Talk-us] destination:street

[Paul Norman]

On 1/19/2017 5:00 PM, Martijn van Exel wrote:
Looking at a random one, http://www.openstreetmap.org/way/34154734 / 
http://openstreetcam.org/details/10767/4194 — I think in the US we 
would just map this as destination=Carman Road;Iriquois and 
destination:ref=1


That is how it would be typically mapped in Canada in my experience, 
although it might have a prefix to the ref.


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

Re: [OSM-talk] Wikipedia/Wikidata admins cleanup

[Paul Norman]

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


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



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

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

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


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


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


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

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

[Paul Norman]

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


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


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


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

Re: [Talk-ca] Community Conduct

[Paul Norman]

On 12/22/2016 3:21 PM, James wrote:
As pnorman has said in the past( 
https://lists.openstreetmap.org/pipermail/talk-ca/2016-September/007260.html):


/ Uploaded in small enough parts that the changesets make sense. This 
means never uploading more than 50k objects at once, and typically 
fewer than 10k./



I try to keep my changes under 10k, but with buildings, nodes multiply 
quickly as there are minimum 4 per building(rare usually average 6-10 
depending on complexity)


The numbers quoted are in the context of an *import *where the concerns 
are the ability to revert, working with the changeset in other tools, 
not leaving stray nodes in the database, not splitting one upload over 
multiple changesets, and not having a broken upload. I wouldn't 
recommend exceeding them for any work, but a non-import is out of the 
scope of the CanVec post linked.


Personally, I'd get worried about conflicts, lost work, and want to 
upload well before 1k changes, let alone 10k. Those often aren't a 
problem with an import, or if they are they can be easier to solve, but 
with normal mapping solving them often requires more thought.


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

Re: [Talk-us] manifesto

[Paul Norman]

On 11/30/2016 9:30 AM, mart...@openstreetmap.us wrote:
It is also not too late to become a candidate for the board elections. 
Let us know at bo...@openstreetmap.us  
if you have any questions.


The wiki says nominations closed on the 27th, and candidates needed to 
have their name and position statement by then. Was the wiki incorrectly 
copied from last year?
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Okanogan-Wenatchee National Forest (landuse=forest and US National forests again)

[Paul Norman]

On 11/29/2016 7:14 AM, Andy Townsend wrote:
All I know of the area is"lots of parts of it do have lots of trees", 
but does the landuse=forest assignment make sense on the National 
Forest boundary, or should it be on the forested areas within?  I 
mention this here rather because I'm sure there are people here 
familiar with the area, which I'm not.


The forested areas within. Or natural=wood, both get used in practice, 
but that's an entire different mess.


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

Re: [Talk-us] Fresno Parcels Deletion proposal

[Paul Norman]

On 11/26/2016 2:43 PM, Brian M Hamlin wrote:

Hi All -

  people are invited to see a blog post on the topic of Fresno County 
landuse=residential legal records, aka PARCEL.


  You can find the blog address in my signature.
   thanks very much


I've long supported cleaning up the Fresno import by removing 
landuse=residential, and have done some work on remapping the areas 
myself, but I've found there's too much cleanup of the import to do by 
hand. There's some issues with 
http://blog.light42.com/wordpress/?p=2553, mainly with parts of the 
process which aren't identified:


- how to delete the data;
- how to identify the data;
- how data edited by users since the import will be identified and handled;
- problems with disentangling the imported data from other data; and
- when the process is defined better, it should be on the OSM wiki.

So, I'm supportive in principle, but there aren't enough details yet.

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