Nov 8, 2020, 05:31 by mach...@gmail.com:
> I absolutely agree with Seth, OSM should switch to vector tiles ASAP.
>
Note that OSM would not switch to vector tiles. At most one more rendering
would switch
to vector tiles.
For OSM Carto see
https://github.com/gravitystorm/openstreetmap-carto/i
Hi Joseph,
retaining wall [1] is applicable to whatever area
Il dom 8 nov 2020, 06:50 Joseph Eisenberg ha
scritto:
> Is there a specific tag or method for mapping terraced farmland?
>
[1] https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dretaining_wall
>
_
2020-11-08, sk, 00:00 Anders Torger rašė:
> Maybe this is self-evident to anyone that knows more about this than I
> do, but I have to ask, are you saying that when we have to implement
> generalization to be able to serve vector tiles, it's also natural to
> include generalization of names? Meanin
Is there a specific tag or method for mapping terraced farmland?
In areas with any amount of slope, terraces are built so that areas of
cropland can be flood irrigated. This is very common in rice-growing
regions, and also used for some other crops which grow best in flooded
land.
The presence of
I absolutely agree with Seth, OSM should switch to vector tiles ASAP. And
there should be several specialized layers: general car navigation map,
sport map for hiking/cycling/skiing, transportation. All of that would be
possible with vector tiles which are less computationally demanding to
create.
I'm don't know that much cartography terms and techniques, I only know
what I know from using maps. I have noted though that traditional maps
simplify the geographic shapes depending on scale. Sometimes in
interesting ways, instead of removing small islands they are sometimes
drawn bigger inste
On Nov 7, 2020, at 9:14 AM, Anders Torger wrote:
> Hello Steve,
> thanks for that wonderful and inspiring post! I'll surely think about
> doing-what-can-be-done-with-the-current-tools-at-hand, and think about that
> the work can be built upon by others in the future. Most inspiring!
You are wel
One more thing to consider: generalisation is one of the most
important things for cartography, but it is also extremely important
for vector tiles. 2-3 years ago we've played with government data and
it produced huge (up to 4MB) vector tiles (pbf) for middle scales
(zoom 8-12). Browsers (especiall
Hello Tomas,
I just need to comment specifically on your https://topo.openmap.lt --
I'm very impressed!
(I had to run it in Chrome, it didn't render properly in my Firefox, but
this vector stuff is new tech and Linux Firefox seems to have some
issues with that.)
/Anders
On 2020-11-07 07:5
Yes, maps are definitely primary way how OSM data is used.
I just wanted to note that it is not only way how it is used.
Nov 7, 2020, 19:42 by and...@torger.se:
>
> Yes good point. Actually, I don't even know if cartography makes the top ten
> list of how OSM data is used. Does it?
>
>
> For m
Yes good point. Actually, I don't even know if cartography makes the top
ten list of how OSM data is used. Does it?
For me personally cartography is *the* thing, and I guess I am guilty
for arguing from my own perspective. Sure I use basic road routing
capabilities too that stem from the data,
Sorry for replying to myself again, but I realized the link I shared was
not a true example, although the maps I linked to are built to look
similar to vector data they are delivered as png tiles, and least on my
computer (some services switch automatically between pixel/vector).
This link (of
Thanks for those valuable points.
I'm a layman, watching at OSM form the outside as a casual mapper and
user. You're an expert on the inside. My perspective is thus limited,
and also limited is the understanding of technical and infrastructure
challenges.
Regarding of comparing to government
Hello Steve,
thanks for that wonderful and inspiring post! I'll surely think about
doing-what-can-be-done-with-the-current-tools-at-hand, and think about
that the work can be built upon by others in the future. Most inspiring!
And I'll also clarify, I don't expect some Swiss cartographic artw
A move to prioritize cartography is probably not easy and there are lots
of challenges. But I think it can be much better than it is today.
I'm not too surprised that people in general would prefer google map
with less information. The thing with cartography designed for paper is
that it's ext
On Sat, 7 Nov 2020 at 14:26, Brian M. Sperlongano
wrote:
> I note that "visitation room" is a term that describes "A room designated
> in the funeral home for the deceased to lie before the funeral so that
> people can view the deceased."
>
I hadn't come across the term in the UK, but that could
Nov 7, 2020, 16:41 by and...@torger.se:
> And in the end it's about the resulting map.
>
Not only, OSM data is also used in other ways.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Probably the database should be organized in layers. The more
information there is, the messier it becomes to have everything visible
at once. With JOSM you can sort of simulate layers with filters on tags
(I use that feature all the time), so I'm not sure if it actually needs
to be layers in t
I actually just found that article about OSM’s problems.
One of the major topics mentioned, the fact that OSM acts as a database and
not a map, and that this acts as a hinderance to the expansion and
development of the project, is very true.
As a result, I’ve came to think that implementing Vecto
I wanted to quickly comment on two things where a misleading narrative seems to
be represented in the discussion here so far.
The first one is the idea that OSM community cartography is being held back by
the lack of computing power. It is not. The resources that would be required
to run vari
I note that "visitation room" is a term that describes "A room designated
in the funeral home for the deceased to lie before the funeral so that
people can view the deceased." Conveniently, it carries no religious
connotation.
Some cursory searching indicates that this term is in use both in the
2020-11-07, št, 14:37 Jeremy Harris rašė:
> Alternatively, could the rendering job be done by the client needing the
> out-of-date tile, and resubmitted to the server?
As Mateusz has pointed out, this has already existed, but one of the
reasons it was discontinued (along with the lack of interes
Nov 7, 2020, 13:33 by j...@wizmail.org:
> On 07/11/2020 11:13, Walker Bradley wrote:
>
>> Computing power seems to be a constraint struggle without greater
>> fundraising capacity, so could there be some work done on the rendering
>> process? Could we do a specific and targeted fundraising ef
On 07/11/2020 11:13, Walker Bradley wrote:
Computing power seems to be a constraint struggle without greater fundraising
capacity, so could there be some work done on the rendering process? Could we
do a specific and targeted fundraising effort to improve the renderer to make
as much use of th
On Nov 6, 2020, at 1:51 PM, Anders Torger wrote:
> I'd love to help out if the workload and chance of success was reasonable,
> but I'm a bit wary about the tagging proposal process. Most of my mapping
> contributions is simple things like correcting and adding roads so all the
> various online
Le 7 novembre 2020 12:47:45 GMT+01:00, Tomas Straupis
a écrit :
> Fuzzy features (like
>continents, mountain ranges, bays etc. should probably be moved to a
>separate database).
>
I often thought an 'Openlabelmap' database containing geometries to help with
the labeling of such features could
Hi,
On 11/6/20 19:31, Anders Torger wrote:
> ** Tagging bays and straits as areas work great, as the renderer gets
> and idea how prominent it is and it can make proper text sizing and they
> can be seen even if zoomed out if the area is large. Lots of our lakes,
> even quite small ones have sub-n
2020-11-07, št, 13:24 Anders Torger rašė:
> However, and this is a big however, I think that the face of
> openstreetmap really need to be a cartographic sound map.
During personal meetings as well as during different presentations
in conferences I've been showing people two maps (one was google
Others can correct me if I'm wrong, but I think the problem is not
really limited computing power, but it's a design thing. Update speed
has a really high priority, too high if you ask me. So regardless of
computer power available, we want the fastest update speed possible.
For the main servers
This is great information, I didn't know about your project, very very
interesting. I have recently come to understand the OSM-Carto technical
challenges recently. I haven't given it much of a thought as a casual
mapper for the past two years, just been a bit disappointed with how it
looks.
I
Dear all,
First off I would like to state how fascinating this conversation is. I’ve
been working with OSM data for years, and I never understood how the rendering
actually worked. It seems like the challenges are two-fold. One is computing
power and the other seems to be rendering algorithm
Sorry, I'm no expert so I should have been more humble and not state it
as a "fact". I *think* multipolygon was supposed to be a way to make
single entities of complex shapes, and these groups are not really
single entities, but multiple entities with single names, and thus I
find it "superior" to
Hello Graeme,
the nature of these gravel yards vary a bit, but they can look like
this:
https://showmystreet.com/#12q73u_a3n0t_1v.a_-4f42
and they were made maybe 50 years ago. This one probably comes from the
time the road was straightened in the 1970s or so. But there are also
these thing
33 matches
Mail list logo
