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

[Matthijs Melissen]

Dear all,

Today, v2.27.0 of the openstreetmap-carto stylesheet has been
released and rolled out to the openstreetmap.org servers.

Changes include:

* The following tags are now rendered: amenity=food_court,
amenity=doctors, natural=scree, natural=shingle, natural=bare_rock,
leisure=water_park, leisure=miniature_golf.
* The tags leisure=golf_course is now rendered with an icon.
* The following tags are no longer rendered: natural=desert,
military=barracks, and landuse=field are no longer rendered. The tags
natural=sand, landuse=military, and landuse=farmland might in some
cases be replacements.
* New icons for amenity=pharmacy, amenity=atm, amenity=bank,
shop=bakery, and amenity=cinema.
* Slightly improved icon for amenity=hospital, tourism=museum,
amenity=recycling, tourism=camping, leisure=playground, places of
worship.
* Private leisure=playground and amenity=recycling are now rendered transparent
* Prison areas are now rendered.
* Various bug fixes.

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

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

-- Matthijs

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

Re: [OSM-talk] [Imports] amenity=bicycle_repair_station :::: only 18 so far

[Peter Wendorff]

Hi,

Adding option 4, already used on many other imports:

Use some externa repository for manual checkup, as done e.g. for fuel
stations [1], where the list of fuel stations was spread via wiki and
some other tool I don't recall exactly.

This allows to verify the progress (let importing users add a link to
the objects after their import), and it allows to verify the data. I
remember we checked most of the items on different sources as well, like
websites and aerials (you see fuel stations on imagery usually).

regards
Peter

[1]
http://wiki.openstreetmap.org/wiki/Fuel_Station_Data_Germany#Tankpool24.de

Am 26.01.2015 um 19:14 schrieb Dave Corley:
> --
> 
> Message: 5
> Date: Mon, 26 Jan 2015 18:27:43 +0100
> From: JB mailto:jb...@mailoo.org>>
> To: winfi...@gmail.com ,  OpenStreetMap
> talk mailing list
> mailto:talk@openstreetmap.org>>
> Subject: Re: [OSM-talk] [Imports] amenity=bicycle_repair_station 
> only 18 so far
> Message-ID: <54c6790f.1040...@mailoo.org
> >
> Content-Type: text/plain; charset=UTF-8; format=flowed
> 
> Le 26/01/2015 17:59, Jo a écrit :
> > It would indeed be preferable to use OSM Notes for that purpose.
> Ho crap. Instead of importing 500 low-quality POI, just import 500
> low-quality notes…
> So that only the notes DB is a dump, but not the main one.
> Sorry for the bad energy, but please do not consider the note feature as
> a second level one. And for the fun, please close the 10 closer to your
> location :-)
> 
> 
> As I see it there are 3 options here
> 
> 1. Do an import, but its not accurate enough for an import - 500 POI's
> will never be fully vetted. 
> 
> 2. Add a note so that someone can map it either from imagery or a ground
> survey - 500 notes will get checked by individual mappers. 
> 
> 3. Do nothing, stick the data in a drawer and never use it - 500 pieces
> of data never get used by anyone
> 
> To me the only logical choice is #2 when you data is not accurate enough
> for an import but the data itself is useful and something which is wanted 
> 
> All that is needed is a disclaimer added to the note something to the
> effect of "This note is based off an inaccurate source. The bicycle
> repair station is located somewhere within 30 meters of this note. If
> you can easily identify the station, please map it and close this note.
> If note, please add a comment saying it needs a ground survey". 
> 
> This doesn't need to be very complicated. 
> 
> Dave
> 
> 
> ___
> 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] amenity=bicycle_repair_station :::: only 18 so far

[Andreas Goss]

With only 50 some nodes, it is hard to argue for rendering.


I don't think rendering is important here. What would be much better is 
a very simple smartphone app just to find the nearest one and then also 
just integrate it in all the existing bicycle maps.

__
openstreetmap.org/user/AndiG88
wiki.openstreetmap.org/wiki/User:AndiG88‎


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

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

[Peter Wendorff]

Hi,

What if the osm website would allow "custom renderings" within
predefined zoom levels by default, stitching together existing tiles in
that case, which should require much less resources than a complete
custom render, even when cutting down to non-tile boundaries.

For current browsers it should be possible to do that with javascript at
the browser a well.

If we still want to allow the custom zoom rendering, a "fallback" to the
current solution might be possible, but a UI that makes clear that some
predefined zoom levels are to be preferred might, I guess, solve most of
our requests "by accident" as most users probably aren't that specific
in the zoom they query for.

What do you think about that idea?

regards
Peter

Am 26.01.2015 um 13:40 schrieb Tom Hughes:
> On 26/01/15 12:00, Paul Norman wrote:
>> On 1/26/2015 2:58 AM, Dave F. wrote:
>>> I don't know when it was last reviewed, but does this error have bit
>>> of a sensitive trigger? Has the server that runs the process been
>>> upgraded so it can handle a greater number of requests? If so, could
>>> the error's cut in point be relaxed?
>> The thresholds for each server have been adjusted multiple times and
>> will probably continue to be so. Even if the load cutoff is increased
>> there will be times when individual render requests are rejected for a
>> few days in a row - stylesheet updates being the main one. It is
>> considered more important to update the map rendering than to do a
>> custom render. Personally I don't have many problems generating a custom
>> render from osm.org, but I'm on a different timezone and keep different
>> hours, which makes it hard to compare. I also get directed to a
>> different server much of the time.
> 
> I suspect main difference is that you're hitting orm and Dave is hitting
> yevaud. There is an ops ticket open for our efforts to get yevaud
> upgraded to improve the performance:
> 
> https://github.com/openstreetmap/operations/issues/5
> 
> Tom
> 


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

Re: [OSM-talk] Addresses interpolation

[Sylvain Maillard]

Hi,

by looking at the point with wrong street name, I can tell you that the
last contibutor is (now) one of the most experienced contributors in France.
I'm not sure where the error come from, but I would say it was one error
among other good changes ;)

I will send him an email about this error ...

Sylvain




2015-01-27 12:48 GMT+01:00 Dmitry Kiselev :

>
>
> ...and leave that editor free to make the same mistake again and again.
> They probably didn't realise they'd made a mistake, and a friendly note
> from you might stop the problem occurring again.
>
> Also, while they're correcting the mistake they've made, they may also
> spot places in the same area where the map needs updating. As a remote
> mapper, you're not going to be able to do this.
>
> That's why using QA tools is fine, but just blindly "fixing" errors
> without communicating with local mappers doesn't produce the best
> outcome for OSM overall.
>
> I do understand the urge to "fix" inconsistencies in the data like this,
> but until every single geographic feature on the face of the Earth is
> represented in OSM somehow, it shouldn't be our highest priority.
>
> J.
>
>
> Seems to much extroversive for me.
>
> ___
> 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] [Imports] amenity=bicycle_repair_station :::: only 18 so far

[colliar]

Am 27.01.2015 um 08:43 schrieb Paul Johnson:> On Mon, Jan 26, 2015 at
11:27 AM, JB  > wrote:
>
> Le 26/01/2015 17:59, Jo a écrit :
>
> It would indeed be preferable to use OSM Notes for that purpose.
>
> Ho crap. Instead of importing 500 low-quality POI, just import 500
> low-quality notes…
> So that only the notes DB is a dump, but not the main one.
> Sorry for the bad energy, but please do not consider the note
> feature as a second level one. And for the fun, please close the 10
> closer to your location :-)
>
>
> If there was high quality information to be had, it'd be in the map
> already instead of a note...notes have information that need a little
> more polish before it's usable data.  I don't see an issue with throwing
> a few dozen extra notes around when we have field QA tools like Osmand
> that make finding them in the field easy.

+1

as far as I understand it these POIs where collected by some crowed and
every one could have opened this note by him-/herself without Bryce as
moderator.

In future it would be much better if the person who is collecting the
data, simply openes a note. E.g. this way we hopefully would not have to
search on the other side of the street as the note is often better
placed regarding geometry.

cu fly


0xE8F56581.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Addresses interpolation

[Dmitry Kiselev]

>...and leave that editor free to make the same mistake again and again.
>They probably didn't realise they'd made a mistake, and a friendly note
>from you might stop the problem occurring again.
>
>Also, while they're correcting the mistake they've made, they may also
>spot places in the same area where the map needs updating. As a remote
>mapper, you're not going to be able to do this.
>
>That's why using QA tools is fine, but just blindly "fixing" errors
>without communicating with local mappers doesn't produce the best
>outcome for OSM overall.
>
>I do understand the urge to "fix" inconsistencies in the data like this,
>but until every single geographic feature on the face of the Earth is
>represented in OSM somehow, it shouldn't be our highest priority.
>
>J.

Seems to much extroversive for me.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Addresses interpolation

[Jonathan Bennett]

On 27/01/2015 10:24, Dmitry Kiselev wrote:
> 
>> Have you asked cquest, the editor who created it? They're the best
>> person to answer this question.
> 
> I have a validator or at least addr:interpolation parser, so I have a
> lots of examples like this
> made by different editors.
> 
> So, if it's not an local trait, it's much more easy for me to just fix them.

...and leave that editor free to make the same mistake again and again.
They probably didn't realise they'd made a mistake, and a friendly note
from you might stop the problem occurring again.

Also, while they're correcting the mistake they've made, they may also
spot places in the same area where the map needs updating. As a remote
mapper, you're not going to be able to do this.

That's why using QA tools is fine, but just blindly "fixing" errors
without communicating with local mappers doesn't produce the best
outcome for OSM overall.

I do understand the urge to "fix" inconsistencies in the data like this,
but until every single geographic feature on the face of the Earth is
represented in OSM somehow, it shouldn't be our highest priority.

J.

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

Re: [OSM-talk] Quay

[Jean-Marc Liotier]

(This discussion originated on talk - crossposted to tagging on 
Malcolm's suggestion)


On 26/01/2015 21:16, Malcolm Herring wrote:

On 26/01/2015 19:23, Jean-Marc Liotier wrote:
http://wiki.openstreetmap.org/wiki/Proposed_features/Harbour#Quay 
mentions that "a quay will normally be tagged as part of the 
coastline natural=coastline". Apart from that I found no clue 
anywhere else about how a quay should be tagged... Am I missing 
something ? Considering how well-used man_made=pier is, I am 
surprised that quays get such scant attention. man_made=quay anyone ? 
To quote the IHO dictionary: "quay. A WHARF approximately parallel to 
the SHORELINE and accommodating ships on one side only, the other side 
being attached to the SHORE. It is usually of solid construction, as 
contrasted with the open pile construction usually used for PIERS."


So yes, your reasoning is correct & that section of the coastline that 
forms the quay could indeed be tagged "man_made=quay".


Yes, this is about what I had in mind:
- Either take a section of natural=coastline and overload it with 
man_made=quay

- Or draw a dedicated man_made=quay way on top of a natural=coastline

I have no idea which one would be best. I lean towards the first one for 
easier editing - ways exactly on top of each other are difficult to select.



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

Re: [OSM-talk] Addresses interpolation

[Dmitry Kiselev]

> Have you asked cquest, the editor who created it? They're the best 
> person to answer this question.

I have a validator or at least addr:interpolation parser, so I have a lots of 
examples like this 
made by different editors. 

So, if it's not an local trait, it's much more easy for me to just fix them.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Fwd: Re: [Imports] amenity=bicycle_repair_station :::: only 18 so far

[Paul Johnson]

On Mon, Jan 26, 2015 at 1:40 PM, SomeoneElse  wrote:

> On 26/01/2015 19:19, Bryce Nesbitt wrote:
>
>>
>> 2) Nobody seems to mind if a school POI is off by 30 meters.  But the
>> people do seem to care for bicycle repair stations.
>>
>>
> Citation needed, I think.  That may be true in the US (were schools
> imported there?) but I'd be very surprised if in the UK there were many
> school POI nodes (of which there are still a few) that were actually
> outside the school grounds.  A quick peek at a couple of areas in the UK in
> taginfo (including ones with fewer local mappers) suggest most schools are
> mapped as areas, and I'd expect them to be as accurate the aerial imagery
> locally, which is certainly better than 30m.


Schools were imported (from GNIS), as far as I can tell.  Sadly apparently
the government doesn't even know it's own territory that well, so nodes for
some schools (and churches, and airfields, and post offices, and similar
amenities) that were removed (or destroyed through some means, or in the
case of many, especially remote, post offices, just plain *abandoned*, but
left standing) years to decades before the imported data was generated
ended up in OSM.  Go back a few years and the situation was far worse, I'm
sure "TIGER import considered harmful" should bring plenty of calls for a
wide-scale revert.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk