i am fine with that.
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
ive conflict of interest with every decision of substance that is being
made.
Please note although these might sound like rhetorical questions they are not,
i am honestly interested in how the board envisions this to work.
--
Christoph Hormann
http://ww
iD's power over the development tagging and tag meaning in OSM
is primarily either destructive or affirmative. iD has the power to wreak
havoc and destroy a tag or it can affirm and support a trend in already
predominantly consistent use. Same is the case with OSM-Carto.
--
Christop
think the quoted change applies to the multi/flex
backends only, though the documentation is not very clear in the
terminology used ('pgsql output' vs. 'pgsql backend').
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
oordinate rounding to the vector tile coordinate
grid but also the subjective choice of per feature Douglas-Peucker line
compression. See
https://github.com/postgis/postgis/pull/463
for the well argued suggestion not to do that. The way_area filtering
is explicit in the SQL code.
--
Chri
zoom
levels there are other options based on pre-rasterizing the data which
would still allow using the benefits of client side styling. I have
demonstrated that in the past.
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetm
ifferent types of polygons. While it is in
principle possible to show fill patterns in continuous zooming in an
ergonomic fashion i have so far never seen maps in the wild doing that.
This would be something to consider if you want to create a style
similar in the richness of landcov
agery services and to a much broader
understanding of "high resolution". ;-)
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
can find the files as well on:
https://github.com/nvkelso/natural-earth-vector/tree/v4.0.0/110m_cultural
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
t the tile manager could be completely projection
agnostic, it would not even need to know what projection the map is in,
it would just need to know the bounds of tile 0/0/0 in the desired
projection - and divide these bounds as needed to generate the
rendering reques
On Saturday 23 June 2018, Christoph Hormann wrote:
> [...]
>
> I still hope Lucas will write up a few details about the technical
> approach that would enable you to more easily re-implement this in a
> different style.
By the way Lucas has already done so, you can find
apserver can but Mapnik cannot.
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
things through a bit better in some cases and
make tools a bit more generic which also makes them look more
attractive to third parties obviously. Still there is a lot of 'just
another version of the same thing essentially' in what they did.
-
e programs were originally designed.
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
he options offered by the cartographic
mainstream within the technological framework used - and which, due to
Mapnik and CartoCSS being essentially unmaintained, becomes more narrow
and limiting every year.
--
Christoph Hormann
http://www.imagico.de/
__
OSMF ToU. I would also assume that (b) most likely would not
require you to use OAuth with every request, you probably could just
use OAuth when people register with you for an API key.
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing li
ve to consider the share-alike requirements of the ODbL.
And at least for history data where correct interpretation of the
geodata depends on the timestamps you will have a hard time
interpreting this as a collective database.
--
Christoph Hormann
http://www.imagico.de/
_
sensitive
content switch on youtube.
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
olved' case)
are plausible interpretations. So there are no simple yes/no answer to
the whole subject - you would need to draw a line somewhere -
preferably one that, as i phrased it in legal-talk recently, "supports
desirable and harmless use cases but does not create loopholes against
the spirit
on so called AI methods these
days concentrates on data processing after training you can equally try
to use such methods more like a memory device.
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
erwhelming - both in terms of "fully automated"
and "successful".
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
space 1700 distinct
colors is very coarse.
I don't know if Tangram allows defining custom color conversion
functions in some way - i am not even sure how the native color format
is defined, i.e. if that is sRGB or linear color space as you would
normally expect with OpenGL:
https://mapzen.com/docu
In the client style the method to specify colors seems rather odd to
me - is this some kind of standard in this field or is this just an
invention of you?
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@op
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/
_
ols and development goals) is generally
superior for innovation and progress in general compared to trying to
be universally inclusive w.r.t. feature and design ideas or
communication and cooperation styles within projects.
--
Christoph Hormann
http://www.imagico.de/
__
s
are created by the same user.
If you practically want to reverse engineer user identities from a
planet file with user info stripped looking at the data itself and
mapper specific data charateristics (tag combinations, the way
geometries are drawn) would likely be more useful than v
the geometry
(i.e. coordinates) and tags.
So what is the special thing from a legal standpoint about versions and
timestamps compared to geometries and tags?
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetm
to decrease. I don't know at what point this stops
> being true.
I would expect this to happen pretty fast, possibly 8x8 is already at or
near the top. But it will likely depend quite a bit on the hardware
used and the specific rendering task.
--
Christoph Horma
that when two roads connect this is not a smooth
transit. It is not even defined if when a way approximates a smooth
form the nodes of the way are supposed to be on the curve or if they
should be placed so the average distance of the way to the curve is
reetmap/chef/issues/124
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
t the moment this is all fairly theoretical but i none the less
wanted to mention this as a suggestion to keep this in mind when
contemplating ideas on file formats.
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetm
uiltup areas at z8/9.
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
hub.com/openstreetmap/openstreetmap-website/issues/1446#issuecomment-282233549
Everyone is entitled to disagree with that but you'd also have to ask
yourself why the outlined solution is not acceptable for you.
--
Christoph Hormann
http://www.imagico.de/
___
ect.mml is just a renamed project.yaml.
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
dmin_level 2 a better way
would be to classify this based on topology - i.e. all boundaries that
are only part of one admin_level 2 relation are maritime boundaries.
On the higher admin levels this is more complicated of course and not
easy to solve.
--
Christoph Hormann
http://ww
describes the perceptual error when viewing the
rendered geometry (which is evidently not the case).
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
eys and
tokens means the website is known to the tile provider even without a
referrer. So you'd just punish the free services by withholding them
information others get despite these measures.
--
Christoph Hormann
http://www.imagico.de/
___
dev m
c.
By the way currently
http://wiki.openstreetmap.org/wiki/Tile_usage_policy
does not list any companies that provide drop in replacement services
for the standard style. Using the services listed there websites would
be forced to switch to a different style.
--
Christoph
gt; to use CartoCSS filters. A z14 tile needs to have all the data a z19
> tile needs to render.
The problem is not really filtering - this would be simple using
additional attributes generated from SQL. The real difficulty is
geometry processing.
--
Christoph Hormann
http://www.imagic
meter at z14 - but when this occurs it would be visible and possibly
surprising).
And if i understand you correctly this also means you cannot render any
features differently on z14 and any higher zoom level based on
processing done in SQL - unless you duplicate them into different
separate lay
ap-carto-vector-tiles
>
Looking at your changes a significant part seems to be dealing with
way_pixels and indicates that the meaning of way_pixels in your version
is quite different from that in the normal standard style. Could you
explain that? You do not seem to have changed the SQL.
--
l case where an untagged node is a relation member but
in principle this is possible and could make sense.
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
-split-regular-4326.zip
I assume this change will be an improvement for the majority of users
but if there are data users for whom this might cause problems please
let us know.
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev
ith natural=coastline.
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
Because the ford key is currently not in the rendering database. See:
https://github.com/gravitystorm/openstreetmap-carto/issues/267
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
unless your tiles are not zoom level specific you are
screwed.
These points apply to all generic geometry data in the tiles, any data
specifically generated for rendering like label positions etc. is
normally projection specific anyway.
--
Christoph Hormann
http://ww
to select one projection from the very
beginning and you stay bound to it or need fully separate setups for
every projection you want to offer.
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
ferent styles from the same infrastructure
(as most vector tiles map providers do) there is certainly potential
for energy saving by caching the vector representations on the server
side. If the way this is done with current vector tiles stacks is the
most efficient approach for that is a
map-carto
[3] For another example of where wikimedia maps fails miserably here
see:
https://maps.wikimedia.org/#18/47.99579/7.85194
http://www.openstreetmap.org/#map=18/47.99579/7.85194
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
out significant losses.
Your method by the way simply overlays the different data sets which
will lead to significant steps at the edges due to differences in
height calibration.
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
=*
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
to
mushy results, you want better acuity with the same amount of detail.
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
levels. Also the maritime
boundaries are trimmed to where they are actually useful.
Some more background information is available on
http://blog.imagico.de/rendering-boundaries/
and a simple map showing the data on
http://maps.imagico.de/#map=3/55.0/0.0r=coastlineo=7ui=0
--
Christoph Hormann
from the exact mode
of operation. For a developer it is always more interesting to work on
something new but it would be good to establish that the work on a
style change does not end with it being deployed.
--
Christoph Hormann
http://www.imagico.de
that much
better than it was two years ago. Some things are improved but these
improvements also introduced a lot of new issues.
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org
-carto/pull/941#issuecomment-58766694
[2] https://github.com/gravitystorm/openstreetmap-carto/pull/725
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
(waterway tag but not waterway=riverbank)
* waterway relations
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
point, if you can distinguish between the waterway
relation and such stray individual waterways this is much easier. But
of course if the relation turns up reliably at the first place in the
list this is much less critical.
--
Christoph Hormann
http://www.imagico.de
-of-the-antarctic-land-ice/
[3] https://github.com/imagico/icesheet_proc
[4] http://www.imagico.de/map/icesheet_download_en.php
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
://wiki.openstreetmap.org/wiki/User:Mrwojo/builtup_area.shp
[2] http://www.imagico.de/map/osm_builtup_en.php
[3] http://www.imagico.de/map/osm_builtup_en.php#download
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetmap.org
https
for manually mapping areas with place=* but keep in mind
measuring object density is always specific to the scale you look at
and there is no natural scale of settlements you can base this on.
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing
are going to adapt the standard mapnik style you also might want
to read
http://wiki.openstreetmap.org/wiki/Polar_Regions_Rendering_Issues
Would be great to see more polar maps by the way.
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev
wonder about the coordinates - that's (50 900) and
(55 905) in UTM zone 47. And of course this does not work near
the equator.
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetmap.org
https
.
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
can be. A frequent mistake in common practice
armchair mapping is that people regard the image as the truth rather
than a most likely inaccurate depiction of the truth. Having several
images available can help here.
--
Christoph Hormann
http://www.imagico.de
and updates on the conference. You should submit by
February 28.
We're looking forward to seeing you in Karlsruhe in June!
On behalf of the SOTM-EU 2014 program committee,
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev
incorporated into
the production map is much less in those areas.
Greetings,
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
,
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
that can - if at all - only be relied on locally if
consistency has been maintained by local mappers or if most of the data
is based on a well structured import.
Greetings,
Christoph
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
of the adjacent one at the same time. If you'd do
that the edges could have any length, they would still fit after the
reprojection (although you could get intersections between the actual
coastline and the splitting lines).
--
Christoph Hormann
http://www.imagico.de
and would not hamper real improvements of the data.
I don't know how often you discard the new data based on comparison with
previous day data but the above would be an alternative to that.
Greetings,
--
Christoph Hormann
http://www.imagico.de/
___
dev
the same also for other geometries would be problematic since
on a sphere you have no reliable way to decide about inside and outside
of a (large) polygon without the orientation convention of the
coastlines.
--
Christoph Hormann
http://www.imagico.de
OSMCoastline determine the matching nodes on its
own and make the connection itself (which is exactly what Jochen did -
although at the moment only for the special case of the southmost
line).
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
myself so if you need
hillshade images for the lower zoom levels i could provide them - for
zoom=2 with 6000km map area (i think that's what you are using as
well):
http://www.imagico.de/files/gshade_2_0_0.tif.bz2
Greetings,
--
Christoph Hormann
http://www.imagico.de
://www.openstreetmap.org/browse/way/22721484
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
://wiki.openstreetmap.org/wiki/User:Imagico/coastline_problems_for_generalization
The run for the whole earth takes about 6 hours (just the
generalization, osmcoastline not included).
Greetings,
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing
/7724629
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
generalization is always a lot about subjective choices so it
is perfectly fine to prefer a different approach. If you can point out
disadvantages of my files when compared to alternative techniques in
actual appearance in rendering that would be very useful.
--
Christoph Hormann
http
/map_en.php
[5]
http://wiki.openstreetmap.org/wiki/User:Imagico/coastline_problems_for_generalization
Greetings,
--
Christoph Hormann
http://www.imagico.de/
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
79 matches
Mail list logo
