Re: [OSM-dev] Place names tagging, rendering and processing

2017-10-11 Thread Andrey Novikov 
As a data consumer I discard area for labeling if it contains node with the
same place= and name= keys. This is not 100% safe but removes major label
duplications from my map.

On Sun, Sep 10, 2017 at 10:45 PM Daniel Koć  wrote:

> Sorry for cross-posting on 3 lists, but this subject is rather wide.
>
> There's a big discussion on osm-carto about rendering and tagging
> place=* names, especially when tagged as an area (but also in general):
>
> https://github.com/gravitystorm/openstreetmap-carto/pull/2816
>
> It was also suggested to hear from OSM data consumers to know how they
> handle nodes and areas with place names.
>
> --
> "Probably it's an eternal problem - too many chiefs, too few Indians" [O.
> Muzalyev]
>
>
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev
>
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

[OSM-dev] osmconvert complex-ways breaks some relations

2017-10-11 Thread Andrey Novikov 
I am creating small map extracts with the help of osmconvert (v 0.8.7) and
have noticed that some(!) large area relations are broken (incomplete) in
data outputs despite I use '--complex-ways' argument. Here is the example:

Test relation is: http://www.openstreetmap.org/relation/6193646
If I filter it with osmfilter:

osmfilter --keep="" --keep-relations="@id=6193646" planet.o5m
-o=filtered.o5m

I get 1900 bytes file with complete relation. But if I further apply the
boundary:

osmconvert filtered.o5m -b=135.,-27.0591,137.8125,-24.5271
--complex-ways -o=extract.o5m

I get 1338 bytes file with some ways missing and resulting in incomplete
relation.

Is it a bug or am I missing something?

Regards,
Andrey
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev

Re: [OSM-dev] Wrong node ids in osmupdated planet

2017-10-11 Thread Jochen Topf 
On Wed, Oct 11, 2017 at 10:56:26AM +0300, Ilya Zverev wrote:
> I have downloaded a planet file around... March?.. and have been updating it 
> using osmupdate 0.3H every two weeks or so. And now I've met a curious bug. 
> Look at these way nodes:
> 
> $ ./osmconvert planet-171009.o5m --out-osm | grep -A 3 'changeset="39613682" uid="362997" user="Virgile1994">
>   
>   
> 
> But OSM API gives: http://www.openstreetmap.org/api/0.6/way/419952872
> 
>  timestamp="2016-05-27T21:00:47Z" user="Virgile1994" uid="362997">
> 
> 
> 
> How could this happen?

This way always had those two nodes in it, even in version 1. So it
doesn't look like something went wrong because of a missed change file
or so. But note that the node IDs are both off by 2. Internally o5m uses
delta-encoding when encoding lists of nodes, so if one is off, then the
next one will be off by the same amount. So this is either a bug in
osmupdate/osmconvert or a bit flipped on you due to bad RAM or so.

Jochen
-- 
Jochen Topf  joc...@remote.org  https://www.jochentopf.com/  +49-351-31778688

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

[OSM-dev] Wrong node ids in osmupdated planet

2017-10-11 Thread Ilya Zverev 
Hi,

I have downloaded a planet file around... March?.. and have been updating it 
using osmupdate 0.3H every two weeks or so. And now I've met a curious bug. 
Look at these way nodes:

$ ./osmconvert planet-171009.o5m --out-osm | grep -A 3 '