Re: [OSM-dev] Generalisation

2018-04-16 Thread Tomas Straupis
SwissTopo maps are some of the best examples of generalisation (as
well as other cartography principles/techniques)
https://map.geo.admin.ch/

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


Re: [OSM-dev] Generalisation

2018-04-16 Thread Yves



>
>> You need to keep in mind that both geometric generalization and lossy
>
>> vector data compression operations are largely incompatible with the 
>> current goals of OSM-Carto:
>>
>>
>https://github.com/gravitystorm/openstreetmap-carto/blob/master/CARTOGRAPHY.md
>
>I don't think this is true. For example making borders simpler
>increases
>clarity, while previous state was creating optical illusions.
>
Also, generalizing buildings could for instance give something nice at low zoom 
instead of only landuse=residential. Nothing really contradictory to the 
described goal here. 


Yves

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


Re: [OSM-dev] Generalisation

2018-04-16 Thread Martin Koppenhoefer
2018-04-16 18:34 GMT+02:00 Marco Boeringa :

>
> No, buildings are not the most interesting. I once generalized all
> buildings in Denmark. It only reduced the storage by maybe 5%, at the high
> cost of heavily distorting a large number of them. Most buildings in OSM
> are in fact already in their most generalized state: just 4 nodes. Unless
> you think triangles is a suitable representation ;-).
>


it really depends on the zoom levels (=detail you want) and building
structure. If there is a closed building block there may be a lot of those
4-node-houses which all together could be generalized to one 4 node block.
If there are scattered houses in a rural setting, you still can omit the
smaller ones or make one bigger structure by combining several smaller
ones. Many buildings also do have more than 4 nodes.

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


Re: The (dark) future of Java on desktop

2018-04-16 Thread Vincent Privat
Indeed, I think the JOSM message of the day in September won't be exactly
polite against Oracle!

2018-04-16 20:44 GMT+02:00 Jo :

> Good news! Who needs Oracle anyway :-)
>
> Polyglot
>
> 2018-04-16 20:36 GMT+02:00 Vincent Privat :
>
>> Hello,
>> I got in contact with Jiri Vanek. He might be our saviour.
>> As some of you may know, he's the one behind IcedTea-Web (ITW: the free &
>> open-source implementation of Java WebStart in the IcedTea project):
>> https://icedtea.classpath.org/wiki/IcedTea-Web
>>
>> The project is still actively developed (the 1.8 version is in progress).
>> http://icedtea.classpath.org/hg/icedtea-web/
>>
>> Last year, Jiri added support for Windows, which I validated with the
>> RedHat build.
>> Jiri's also part of the AdoptOpenJdk initiative which aimes to provide a
>> build farm of OpenJDK with certified binaries on all platforms:
>> https://adoptopenjdk.net/releases.html
>>
>> If I understood correctly, these builds are going to provide JavaFX and
>> ITW
>> once the version 1.8 is finished!
>>
>> So we have to test ITW on Windows and macOS to make sure it works with
>> Java
>> 10 and early builds of Java 11. Then we'll have to check if it still works
>> once Oracle completely removes Java WebStart (I don't know the impacts it
>> could have on ITW).
>>
>> I'm currently trying to build & test ITW on Windows.
>>
>> Cheers,
>> Vincent
>>
>> 2018-04-11 20:41 GMT+02:00 Vincent Privat :
>>
>> > One month already and I still don't know what to do regarding WebStart.
>> > I found out this: https://developers.redhat.com/
>> products/openjdk/download/
>> > Red Hat is providing an implementation of OpenJDK 8 on Windows
>> containing:
>> > - OpenJDK
>> > - OpenJFX
>> > - WebStart based on IcedTea-Web
>> > - An auto-update feature (a small simple script registered to Windows
>> Task
>> > Scheduler)
>> >
>> > The good news:
>> > - This is exactly what we would need for JDK 11.
>> > - I tested it and it works perfectly. We have nothing to change in JOSM
>> to
>> > make it work with this runtime.
>> >
>> > The bad news:
>> > - It is only available to Java developers. A (free) RedHat account is
>> > required, and it is forbidden to redistribute it.
>> > - there is a version of Java 9 but it does only contain OpenJDK (thus it
>> > is useless)
>> > - there is no macOS runtime
>> >
>> > Does someone on this list has a professionnal RedHat account, or know
>> > someone there? I'd like to know if we can hope to see RedHat releasing
>> > OpenJDK 11 it as a public runtime, free or charge and not requiring a
>> user
>> > account, which would contain the same components as their OpenJDK 8
>> > version. This way we would only have to tell people to uninstall their
>> > Oracle runtime and install the Red Hat runtime instead.
>> >
>> >
>> > 2018-03-10 18:05 GMT+01:00 Vincent Privat :
>> >
>> >> If we were to abandon AWT/Swing, migrating to SWT might be another
>> >> option. I don't think it would be easy, but at least it's actively
>> >> maintained: https://www.openhub.net/p/swt/contributors/summary
>> >>
>> >> 2018-03-09 10:40 GMT+01:00 Dirk Stöcker :
>> >>
>> >>> On Thu, 8 Mar 2018, Richard wrote:
>> >>>
>> >>> On Thu, Mar 08, 2018 at 08:36:21AM +0100, Frederik Ramm wrote:
>> 
>>  You could sit down today and re-implement everything in, say, C++,
>> and
>> > it would be relatively straightforward, and while the result would
>> not
>> > share any of JOSM's codebase, it would still encapsulate all the
>> > experience and brainpower that has flown into JOSM development over
>> the
>> > years.
>> >
>> 
>>  true in principle but you would need a protable GUI that doesn't
>> suck or
>>  you end up programming for at least 3 platforms with 3 sets of bugs,
>>  3 sets of dependencies etc.
>> 
>> >>>
>> >>> Reimplementing an existing software like JOSM which has an estimated
>> >>> cost of more than hundred development years (
>> >>> https://www.openhub.net/p/josm) in another language in an non-profit
>> OS
>> >>> application is doomed to fail in my eyes. The motivation for a
>> programmer
>> >>> to take an existing software and reimplement everything again is low.
>> For a
>> >>> very long time you will not have something which is usable and
>> inbetween
>> >>> you have tasks to do, but no positive feedback. That may work when the
>> >>> people are paid for it, but not when programmers need to be
>> motivated. I'd
>> >>> consider people beeing motived by such a task very strange. :-)
>> >>>
>> >>> Rather than that if JOSM really dies some of the better ideas of it
>> will
>> >>> be taken and implemented in existing or new software (which BTW is
>> already
>> >>> happening, e.g. osmosis taking the Validator MapCSS or many other
>> things).
>> >>>
>> >>> If there is a way to automatically convert the code and start with a
>> >>> working base, 

Re: The (dark) future of Java on desktop

2018-04-16 Thread Jo
Good news! Who needs Oracle anyway :-)

Polyglot

2018-04-16 20:36 GMT+02:00 Vincent Privat :

> Hello,
> I got in contact with Jiri Vanek. He might be our saviour.
> As some of you may know, he's the one behind IcedTea-Web (ITW: the free &
> open-source implementation of Java WebStart in the IcedTea project):
> https://icedtea.classpath.org/wiki/IcedTea-Web
>
> The project is still actively developed (the 1.8 version is in progress).
> http://icedtea.classpath.org/hg/icedtea-web/
>
> Last year, Jiri added support for Windows, which I validated with the
> RedHat build.
> Jiri's also part of the AdoptOpenJdk initiative which aimes to provide a
> build farm of OpenJDK with certified binaries on all platforms:
> https://adoptopenjdk.net/releases.html
>
> If I understood correctly, these builds are going to provide JavaFX and ITW
> once the version 1.8 is finished!
>
> So we have to test ITW on Windows and macOS to make sure it works with Java
> 10 and early builds of Java 11. Then we'll have to check if it still works
> once Oracle completely removes Java WebStart (I don't know the impacts it
> could have on ITW).
>
> I'm currently trying to build & test ITW on Windows.
>
> Cheers,
> Vincent
>
> 2018-04-11 20:41 GMT+02:00 Vincent Privat :
>
> > One month already and I still don't know what to do regarding WebStart.
> > I found out this: https://developers.redhat.com/
> products/openjdk/download/
> > Red Hat is providing an implementation of OpenJDK 8 on Windows
> containing:
> > - OpenJDK
> > - OpenJFX
> > - WebStart based on IcedTea-Web
> > - An auto-update feature (a small simple script registered to Windows
> Task
> > Scheduler)
> >
> > The good news:
> > - This is exactly what we would need for JDK 11.
> > - I tested it and it works perfectly. We have nothing to change in JOSM
> to
> > make it work with this runtime.
> >
> > The bad news:
> > - It is only available to Java developers. A (free) RedHat account is
> > required, and it is forbidden to redistribute it.
> > - there is a version of Java 9 but it does only contain OpenJDK (thus it
> > is useless)
> > - there is no macOS runtime
> >
> > Does someone on this list has a professionnal RedHat account, or know
> > someone there? I'd like to know if we can hope to see RedHat releasing
> > OpenJDK 11 it as a public runtime, free or charge and not requiring a
> user
> > account, which would contain the same components as their OpenJDK 8
> > version. This way we would only have to tell people to uninstall their
> > Oracle runtime and install the Red Hat runtime instead.
> >
> >
> > 2018-03-10 18:05 GMT+01:00 Vincent Privat :
> >
> >> If we were to abandon AWT/Swing, migrating to SWT might be another
> >> option. I don't think it would be easy, but at least it's actively
> >> maintained: https://www.openhub.net/p/swt/contributors/summary
> >>
> >> 2018-03-09 10:40 GMT+01:00 Dirk Stöcker :
> >>
> >>> On Thu, 8 Mar 2018, Richard wrote:
> >>>
> >>> On Thu, Mar 08, 2018 at 08:36:21AM +0100, Frederik Ramm wrote:
> 
>  You could sit down today and re-implement everything in, say, C++, and
> > it would be relatively straightforward, and while the result would
> not
> > share any of JOSM's codebase, it would still encapsulate all the
> > experience and brainpower that has flown into JOSM development over
> the
> > years.
> >
> 
>  true in principle but you would need a protable GUI that doesn't suck
> or
>  you end up programming for at least 3 platforms with 3 sets of bugs,
>  3 sets of dependencies etc.
> 
> >>>
> >>> Reimplementing an existing software like JOSM which has an estimated
> >>> cost of more than hundred development years (
> >>> https://www.openhub.net/p/josm) in another language in an non-profit
> OS
> >>> application is doomed to fail in my eyes. The motivation for a
> programmer
> >>> to take an existing software and reimplement everything again is low.
> For a
> >>> very long time you will not have something which is usable and
> inbetween
> >>> you have tasks to do, but no positive feedback. That may work when the
> >>> people are paid for it, but not when programmers need to be motivated.
> I'd
> >>> consider people beeing motived by such a task very strange. :-)
> >>>
> >>> Rather than that if JOSM really dies some of the better ideas of it
> will
> >>> be taken and implemented in existing or new software (which BTW is
> already
> >>> happening, e.g. osmosis taking the Validator MapCSS or many other
> things).
> >>>
> >>> If there is a way to automatically convert the code and start with a
> >>> working base, then the situation is different...
> >>>
> >>> But I also don't think this is necessary (ATM).
> >>>
> >>>
> >>> Ciao
> >>> --
> >>> http://www.dstoecker.eu/ (PGP key available)
> >>>
> >>>
> >>
> >
>


Re: The (dark) future of Java on desktop

2018-04-16 Thread Vincent Privat
Hello,
I got in contact with Jiri Vanek. He might be our saviour.
As some of you may know, he's the one behind IcedTea-Web (ITW: the free &
open-source implementation of Java WebStart in the IcedTea project):
https://icedtea.classpath.org/wiki/IcedTea-Web

The project is still actively developed (the 1.8 version is in progress).
http://icedtea.classpath.org/hg/icedtea-web/

Last year, Jiri added support for Windows, which I validated with the
RedHat build.
Jiri's also part of the AdoptOpenJdk initiative which aimes to provide a
build farm of OpenJDK with certified binaries on all platforms:
https://adoptopenjdk.net/releases.html

If I understood correctly, these builds are going to provide JavaFX and ITW
once the version 1.8 is finished!

So we have to test ITW on Windows and macOS to make sure it works with Java
10 and early builds of Java 11. Then we'll have to check if it still works
once Oracle completely removes Java WebStart (I don't know the impacts it
could have on ITW).

I'm currently trying to build & test ITW on Windows.

Cheers,
Vincent

2018-04-11 20:41 GMT+02:00 Vincent Privat :

> One month already and I still don't know what to do regarding WebStart.
> I found out this: https://developers.redhat.com/products/openjdk/download/
> Red Hat is providing an implementation of OpenJDK 8 on Windows containing:
> - OpenJDK
> - OpenJFX
> - WebStart based on IcedTea-Web
> - An auto-update feature (a small simple script registered to Windows Task
> Scheduler)
>
> The good news:
> - This is exactly what we would need for JDK 11.
> - I tested it and it works perfectly. We have nothing to change in JOSM to
> make it work with this runtime.
>
> The bad news:
> - It is only available to Java developers. A (free) RedHat account is
> required, and it is forbidden to redistribute it.
> - there is a version of Java 9 but it does only contain OpenJDK (thus it
> is useless)
> - there is no macOS runtime
>
> Does someone on this list has a professionnal RedHat account, or know
> someone there? I'd like to know if we can hope to see RedHat releasing
> OpenJDK 11 it as a public runtime, free or charge and not requiring a user
> account, which would contain the same components as their OpenJDK 8
> version. This way we would only have to tell people to uninstall their
> Oracle runtime and install the Red Hat runtime instead.
>
>
> 2018-03-10 18:05 GMT+01:00 Vincent Privat :
>
>> If we were to abandon AWT/Swing, migrating to SWT might be another
>> option. I don't think it would be easy, but at least it's actively
>> maintained: https://www.openhub.net/p/swt/contributors/summary
>>
>> 2018-03-09 10:40 GMT+01:00 Dirk Stöcker :
>>
>>> On Thu, 8 Mar 2018, Richard wrote:
>>>
>>> On Thu, Mar 08, 2018 at 08:36:21AM +0100, Frederik Ramm wrote:

 You could sit down today and re-implement everything in, say, C++, and
> it would be relatively straightforward, and while the result would not
> share any of JOSM's codebase, it would still encapsulate all the
> experience and brainpower that has flown into JOSM development over the
> years.
>

 true in principle but you would need a protable GUI that doesn't suck or
 you end up programming for at least 3 platforms with 3 sets of bugs,
 3 sets of dependencies etc.

>>>
>>> Reimplementing an existing software like JOSM which has an estimated
>>> cost of more than hundred development years (
>>> https://www.openhub.net/p/josm) in another language in an non-profit OS
>>> application is doomed to fail in my eyes. The motivation for a programmer
>>> to take an existing software and reimplement everything again is low. For a
>>> very long time you will not have something which is usable and inbetween
>>> you have tasks to do, but no positive feedback. That may work when the
>>> people are paid for it, but not when programmers need to be motivated. I'd
>>> consider people beeing motived by such a task very strange. :-)
>>>
>>> Rather than that if JOSM really dies some of the better ideas of it will
>>> be taken and implemented in existing or new software (which BTW is already
>>> happening, e.g. osmosis taking the Validator MapCSS or many other things).
>>>
>>> If there is a way to automatically convert the code and start with a
>>> working base, then the situation is different...
>>>
>>> But I also don't think this is necessary (ATM).
>>>
>>>
>>> Ciao
>>> --
>>> http://www.dstoecker.eu/ (PGP key available)
>>>
>>>
>>
>


Re: [OSM-dev] Generalisation

2018-04-16 Thread Daniel Koć
W dniu 16.04.2018 o 11:42, Christoph Hormann pisze:

> There are different definitions of what kind of operations and processes 
> you call "generalization".  

Thanks for showing the examples what can be seen as generalization, this
is quite wide subject:

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

On osm-carto we also use types generalization (like meadow and grassland
shown in the same way), which is very different than the one in the
original message.

> You need to keep in mind that both geometric generalization and lossy 
> vector data compression operations are largely incompatible with the 
> current goals of OSM-Carto:
>
> https://github.com/gravitystorm/openstreetmap-carto/blob/master/CARTOGRAPHY.md

I don't think this is true. For example making borders simpler increases
clarity, while previous state was creating optical illusions.

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]



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


Re: [OSM-dev] Generalisation

2018-04-16 Thread Tomas Straupis
2018-04-16 19:34 GMT+03:00 Marco Boeringa wrote:
> No, buildings are not the most interesting. I once generalized all buildings
> in Denmark. It only reduced the storage by maybe 5%, at the high cost of
> heavily distorting a large number of them. Most buildings in OSM are in fact
> already in their most generalized state: just 4 nodes. Unless you think
> triangles is a suitable representation ;-)

  Interesting, what algorithm did you use?

  I'm playing around in Vilnius which has urban houses, big block
houses, industrial zones and old town with lots of connected buildings
of very irregular shapes.
  In Vilnius there are 54267 buildings tagged with 366979 vertexes.
  Clustering them with distance of 5m gets 45810 objects (of course
with the same number of vertexes).
  Removing buildings with area < 100 and having neighbours in < 500
meters I'm left with 28974 buildings with 299224 vertexes.
  Simplification (amalgamating buildings in the cluster and trying to
remove edges < 20m) reduces the number of vertexes to 117108.
  So this is much more than 5%.
  There are still a lot of problems (no triangles:), but I do not
expect number of vertexes to rise considerably.

  Even "dumb" generalisation (st_buffer+- with join=mitter) reduces
vertex count by ~25%.

  Reducing storage/tile size is not the only/main purpose of generalisation.

> Besides, buildings are only shown at high zoom,
> while generalization is most needed and beneficial at
> low zoom. Lastly, most vector generalization algorithms are primarily
> designed and effective for rather smooth and node rich data, like a
> stream-digitized feature, neither of which relates to square buildings.
> Hence  i consider generalizing buildings largely senseless.

  I suspect you're talking about st_simplify(preservetopology) use in
vector tile generators. Which as mentioned earlier is only technically
a "generalisation".
  http://www.gitta.info/Generalisati/en/html/unit_GenProcedure.html

-- 
Tomas

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


Re: [OSM-dev] Generalisation

2018-04-16 Thread Marco Boeringa



No, buildings are not the most interesting. I once generalized all buildings in 
Denmark. It only reduced the storage by maybe 5%, at the high cost of heavily 
distorting a large number of them. Most buildings in OSM are in fact already in 
their most generalized state: just 4 nodes. Unless you think triangles is a 
suitable representation ;-). Besides, buildings are only shown at high zoom, 
while generalization is most needed and beneficial at low zoom. Lastly, most 
vector generalization algorithms are primarily designed and effective for 
rather smooth and node rich data, like a stream-digitized feature, neither of 
which relates to square buildings. Hence  i consider generalizing buildings 
largely senseless.




Outlook voor Android downloaden 













Van: Tomas Straupis 


Verstuurd: maandag 16 april 11:48 


Onderwerp: Re: [OSM-dev] Generalisation 


Aan: Openstreetmap Dev list 






2018-04-16 11:34 GMT+03:00 Martin Koppenhoefer wrote: > There are some 
precomputed / extracted data files though, some of which > contain generalized 
(simplified) data. These are all "external" sources: > Ok, so this is natural 
polygon generalisation. Looking at https://github.com/imagico/coastline_gen the 
method used is to rasterise, process and then vectorise back. I wonder if that 
is better/faster than full vector way: st_clusterwithin, st_union, 
st_buffer(positiveN), st_buffer(negativeN+M), st_buffer(positiveM) with a 
seasoning of st_simplifypresevetopology according to taste. > Another aspect is 
filtering: osm-carto removes features when they would be > very small (pixels 
at a given zoom level) and lead to "noise". Filtering (selection) is 
technically also a generalisation. But you need to group and probably 
amalgamate them before deciding that it is "too small". For example if we have 
a lot of small patches of forest close together (say 1000 patches of 10x10m 
with distance between patches of 1m) you would want to amalgamate them to one 
large forest, not to get rid of them all. Ways and especially buildings are the 
most interesting (difficult) part :-) P.S. GRASS claims to be doing 
displacement and way selection 
(https://grasswiki.osgeo.org/wiki/V.generalize_tutorial) -- Tomas 
___ dev mailing list 
dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev 




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


Re: [OSM-dev] Generalisation

2018-04-16 Thread Christoph Hormann
On Monday 16 April 2018, Martin Koppenhoefer wrote:
> AFAIK, in the osm-carto style there is no generalization on live data
> for performance reasons (because of continuous data updates via
> minutely diffs). There are some precomputed / extracted data files
> though, some of which contain generalized (simplified) data. These
> are all "external" sources:

I think this requires some clarification.

There are different definitions of what kind of operations and processes 
you call "generalization".  But typically selection is considered a 
generalization operation meaning that most of what is shown at all but 
the highest zoom levels is shown with some level of generalization.  
Most selection is rather primitive - based on fixed zoom level 
thresholds, the dreaded way_area filtering etc.  There are very limited 
attempts at some additional sophistication, like for populated place 
rendering at low to mid zoom levels.

When talking about explicit geometric generalization while specifically 
exclusing lossy vector data compression (which is widely 
mischaracterized as generalization) the Natural Earth boundaries at 
z=1-3 is currently the only case.

Lossy vector data compression in addition is currently/historically used 
in the following places:

* Coastlines at z8-9 - the visual impact of this was rather small but 
visible in some areas (in particular with small islands) if you kept an 
eye on it at the transit from z9 to z10.  This has been the case for a 
long time but is essentially superseded by:
* Coastlines at z0-9 since
https://github.com/gravitystorm/openstreetmap-carto/pull/3065
* The administrative boundaries at z4+ since
https://github.com/gravitystorm/openstreetmap-carto/pull/3103

You need to keep in mind that both geometric generalization and lossy 
vector data compression operations are largely incompatible with the 
current goals of OSM-Carto:

https://github.com/gravitystorm/openstreetmap-carto/blob/master/CARTOGRAPHY.md

-- 
Christoph Hormann
http://www.imagico.de/

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


Re: [OSM-dev] Generalisation

2018-04-16 Thread Tomas Straupis
2018-04-16 11:34 GMT+03:00 Martin Koppenhoefer wrote:
> There are some precomputed / extracted data files though, some of which
> contain generalized (simplified) data. These are all "external" sources:
> <...>

  Ok, so this is natural polygon generalisation. Looking at
https://github.com/imagico/coastline_gen the method used is to
rasterise, process and then vectorise back.
  I wonder if that is better/faster than full vector way:
st_clusterwithin, st_union, st_buffer(positiveN),
st_buffer(negativeN+M), st_buffer(positiveM) with a seasoning of
st_simplifypresevetopology according to taste.

> Another aspect is filtering: osm-carto removes features when they would be
> very small (pixels at a given zoom level) and lead to "noise".

  Filtering (selection) is technically also a generalisation.
  But you need to group and probably amalgamate them before deciding
that it is "too small". For example if we have a lot of small patches
of forest close together (say 1000 patches of 10x10m with distance
between patches of 1m) you would want to amalgamate them to one large
forest, not to get rid of them all.

  Ways and especially buildings are the most interesting (difficult) part :-)

P.S. GRASS claims to be doing displacement and way selection
(https://grasswiki.osgeo.org/wiki/V.generalize_tutorial)

-- 
Tomas

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


Re: [OSM-dev] Generalisation

2018-04-16 Thread Martin Koppenhoefer
2018-04-16 10:34 GMT+02:00 Martin Koppenhoefer :

> still AFAIK, 1 and 3 are currently still from natural earth data, the rest
> is from OSM, 2 is a simplfied version of 4, both come from
> openstreetmapdata.org (Christoph and Jochen). Of these, 1-3 are
> containing generalized data.
>


according to Paul Norman in the video recording, also 5 and 6 are
generalized.
Another aspect is filtering: osm-carto removes features when they would be
very small (pixels at a given zoom level) and lead to "noise".

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


Re: [OSM-dev] Generalisation

2018-04-16 Thread Martin Koppenhoefer
AFAIK, in the osm-carto style there is no generalization on live data for
performance reasons (because of continuous data updates via minutely
diffs). There are some precomputed / extracted data files though, some of
which contain generalized (simplified) data. These are all "external"
sources:




   1. world_bnd_m.shp, places.shp, world_boundaries_m.shp
   

   2. simplified_land_polygons.shp
   

   (updated daily)
   3. ne_110m_admin_0_boundary_lines_land.shp
   

   4. land_polygons.shp
   
   (updated daily)
   5. icesheet_polygons.shp
   
   6. icesheet_outlines.shp
   





still AFAIK, 1 and 3 are currently still from natural earth data, the rest
is from OSM, 2 is a simplfied version of 4, both come from
openstreetmapdata.org (Christoph and Jochen). Of these, 1-3 are containing
generalized data.

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