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

[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