and that those can be accepted
(hamlet used as an example). Nature naming is not discussed though.
/Anders
On 2020-12-14 10:41, Anders Torger wrote:
For reference, here's Rijmmoáhpe again, a wetland which is about 4 km
across, consisting of both bog and marsh:
https://www.torger.s
y get to use it and contribute and eventually see the
result.
/Anders
On 2020-12-14 12:39, Frederik Ramm wrote:
Hi,
On 14.12.20 12:20, Anders Torger wrote:
My sense is that OSM community do want naming in nature as well, but
only if it can be made very simple. Unfortunately that is not always
compat
would like to hear how you want to solve the problem instead
though. As you see on the screenshot, the current situation is far from
optimal with lots of tiny name tags where there should be only one.
/Anders
On 2020-12-14 13:28, Christoph Hormann wrote:
Anders Torger hat am 14.12.2020 07:59 geschriebe
For reference, here's Rijmmoáhpe again, a wetland which is about 4 km
across, consisting of both bog and marsh:
https://www.torger.se/anders/downloads/Screenshot_2020-12-13-OpenStreetMap.png
It's located in Muddus national park, Sweden.
I'm quite sure the recommendation Christoph refers to is
Yeah, you may be right, but I see it like this: in cases where "complex"
naming is a reality, complex schemes are unavoidable, if we want to
support it at all. It's not like one would use the most complex method
in every case, just where it's needed. To use an old saying, Einstein I
think:
an acceptable stepping stone, and not the least a good
reminder than something needs to be done.
/Anders
On 2020-12-14 14:01, Anders Torger wrote:
To make a specific answer to "what additional verifiable local
knowledge" this relation is intended to cover, is that the wetland is
a single na
t;tagging for the renderer" (which is often code
for "tagging that I don't like"), these are real, major features that
actually exist in the real world and their absence makes OSM weaker.
On Mon, Dec 14, 2020 at 8:04 AM Anders Torger wrote:
To make a specific answer to "w
On 2020-12-14 15:22, Christoph Hormann wrote:
Anders Torger hat am 14.12.2020 14:01 geschrieben:
But i already explained that the fact that in OSM we add name tags to
parts of roads, waterways, wetlands, forests or woods does not mean
these are somehow separate from other features
when editing as a
multipolygon is also a relation.
/Anders
On 2020-12-15 09:52, Anders Torger wrote:
Yes we actually have some of that up here too. I've chosen generally
not to map it though as one cannot really verify it on the satellite
photos, and here in the vast nature in north it's
oose is
the best so it at least have some chance of survival so that my work
doesn't go to waste. There are more challenges coming up so more
questions will probably land on this list.
/Anders
On 2020-12-12 12:23, Anders Torger wrote:
Sorry, I realize I have a followup question. Is this really the r
Indeed, place=locality seems to be a dead end, it's been misused quite
much and there's talks about removing it from OSM-Carto, and you can't
render good maps from it, so it's technically a poor concept as well. To
render names properly for natural features the renderer needs to know
the
So your advice is to actually skip the parent relation object, and thus
leave the parts separate and related implicitly just by shared borders
and having the same name? Ok, fine by me.
I certainly agree with you that data users probably won't turn complex
patterns into something meaningful,
s that it's a single entity all parts
bordering to the next)
On 2020-12-11 20:55, Anders Torger wrote:
Thanks I'll do it this way then, this actually works and even gets
rendered, although with OSM-Carto it becomes a name tag in each
separate part so not exactly beautiful, but the data is there.
nd to support zoomed in urban contexts, I guess that's where
the money is anyway), but it's not odd features in any way, any
institutionally made map have them.
/Anders
On 2020-12-12 13:55, Martin Koppenhoefer wrote:
sent from a phone
On 12. Dec 2020, at 12:26, Anders Torger wrote:
In the wetla
re concerned. It is easy to get confused, confusion exists
in the map: semantics are blurry in some cases. This gets better
with worldwide consensus, over years. This (how we learn to best tag
and render) is an ongoing long-term OSM process. As a mapper, "tag
accurately first," then let r
It was just an example. Peak is "close enough" for now, and you can
argue that it works for both mountain and individual peaks. That would
be okay, but the problem with that is that there is no information for
the renderer which peaks that should be shown when zoomed out. Some
renderers just
-13 11:10, Ture Pålsson via Tagging wrote:
12 dec. 2020 kl. 16:18 skrev Anders Torger :
Indeed, place=locality seems to be a dead end, it's been misused quite
much and there's talks about removing it from OSM-Carto, and you can't
render good maps from it, so it's technically a poor concept
/Relations/Proposed/Site
On 13-12-2020 11:28, Anders Torger wrote: Here's a real example of how
this naming scheme ends up looking:
https://www.torger.se/anders/downloads/Screenshot_2020-12-13-OpenStreetMap.png
I have put the name on each part which is the enduring recommendation
I've got.
oncept for mappers,
renderers and other data users. If succesful, showcase. If not,
document and delete.
Peter Elderson
Op vr 11 dec. 2020 om 17:11 schreef Anders Torger :
Hello,
I was on this list a while back expressing some frustration over
limitations when tagging nature and thought about
Hello,
I was on this list a while back expressing some frustration over
limitations when tagging nature and thought about getting involved in a
process for change, but I came to realize that it's not feasible for me
in my current life situation, so I've decided to continue be a normal
mapper
Sorry, forgot to add that an alternative to fuzzy areas would be to do
like hamlet/village/town/city etc and have a bunch of these point names
for various natural features that we could place out instead of fuzzy
areas. Do you think that is better?
That combined with an external database for
Hello,
I'm doing further mapping of Swedish national parks, now in the
mountains, and I have noted that natural=fell (habitat over tree line)
is not rendered.
Looking into why it seems that OSM-Carto implementors want more specific
landcover tags to be used. I don't think that (somewhat
11:03, Janko Mihelić wrote:
The fifth alternative is move the big areas to an outside repository:
https://github.com/dieterdreist/OpenGeographyRegions
This might be a great alternative until we find a better solution. And
there might not be a better solution.
Janko
pon, 21. pro 2020. u 10:22 An
ter of this
nature. So I think it would be better with a specific tag that embraces
this property of the land.
/Anders
On 2020-12-21 10:34, Andy Townsend wrote:
On 21/12/2020 07:39, Anders Torger wrote:
Hello,
I'm doing further mapping of Swedish national parks, now in the
mountains, and I ha
to show mappers that there is backing for this tag.
/Anders
On 2020-12-21 10:12, stevea wrote:
On Dec 20, 2020, at 11:39 PM, Anders Torger wrote:
I'm doing further mapping of Swedish national parks, now in the
mountains, and I have noted that natural=fell (habitat over tree line)
is not rendered.
Loo
it over Christmas. I've invested way more time in OSM during the
fall than I initially planned to. Mapping is dangerous, it's easy to get
hooked ;-).
/Anders
On 2020-12-21 15:09, Tomas Straupis wrote:
2020-12-21, pr, 15:54 Anders Torger rašė:
A local renderer would be limited in use
ver intend to make
useful maps for, so then I'll just skip those. There are still other
areas to map.
/Anders
On 2020-12-21 13:57, Frederik Ramm wrote:
Hi,
On 21.12.20 10:20, Anders Torger wrote:
In the mountains we have an number of named plateaus. There is a tag
proposal for natural=plateau
On 2020-12-21 14:38, Tomas Straupis wrote:
2020-12-21, pr, 14:42 Anders Torger rašė:
I personally want to see that the community work for a more defined
mapping baseline with OSM-Carto as a strong reference, used as a
motivational tool for crowd-sourcing, and as it is with the current
provider
I forgot to comment this. Just want to make sure that there is no
misunderstanding: this is not primarily about labeling the Alps or the
Atlantic or the Sahara desert.
It's mainly about making rural and outdoor maps useful for a local
context. Maps that hikers, mountaineers and hunters use
Next question.
In the mountains we have an number of named plateaus. There is a tag
proposal for natural=plateau, but just like with natural=peninsula and
similar tags there is an underlying question that we really need an
answer to first: should we have fuzzy areas or should we not?
motivated to do
so, at least in some places in the world. I want the OSM technical
platform to be ready for that.
/Anders
On 2020-12-21 11:55, stevea wrote:
On Dec 21, 2020, at 2:10 AM, Anders Torger wrote:
I'm sorry if you experience it as that. Maybe I'm a bit too
confrontational, and maybe I
wiki page just documenting how this tag have ended up
being used?
/Anders
On 2020-12-21 18:27, stevea wrote:
On Dec 21, 2020, at 7:10 AM, Tomas Straupis
wrote:
2020-12-21, pr, 16:52 Anders Torger rašė:
But what to do if the things you want doesn't
really fit into what OSM currently is and str
is how one SHOULD tag, though I make a point to say that any
wiki which does that should say so explicitly.
Good luck in your endeavors!
SteveA
On Dec 21, 2020, at 9:56 AM, Anders Torger wrote:
I just discovered a strange(?) thing with the "natural=fell" tag which
I missed at first: o
or capacity to do anything
about it I see a whole different story.
/Anders
On 2020-12-14 19:41, Christoph Hormann wrote:
Anders Torger hat am 14.12.2020 15:49 geschrieben:
Okay, but why does the OSM-Carto renderer, and all other renderers
known
to man(?) make multiple text labels then, when it
Thanks Kevin, point taken ;-)
To summarize. This is the way I interpret this situation:
OSM is a geodatabase, with a design that makes some geodata suitable for
it, others less so. The overall design is not likely to change to accept
more types of geodata, instead we would rely on extra data
ing passionate about a subject. Sorry
for that.
/Anders
On 2020-12-21 22:08, Frederik Ramm wrote:
Anders,
On 12/21/20 21:36, Anders Torger wrote:
Actually it seems to me that thinking about several tags at a time
seems
to be a fairly new concept ;-)
I think this is approximately you
Cluttering could be a problem, but is an easy thing to solve with
filters. As I edit i national parks now I have this huge national park
polygon covering all work, which renders as a flat although
half-transparent color in JOSM. It's easy to remove with a filter
though, but actually I'm not
Maybe we need to split "small" and "large" fuzzy areas into different
concepts. Or at least different discussions, as they are quite different
in terms of how they affect the map and what needs they fulfill.
I do see a risk of edit wars of large fuzzy areas that make great impact
on overview
that your renderer will probably be
the first one implementing this, despite the claims that this is an
established method... but I hope I'm wrong.
/Anders
On 2020-12-14 19:06, Ture Pålsson via Tagging wrote:
14 dec. 2020 kl. 15:49 skrev Anders Torger :
Okay, but why does the OSM-Carto
e is priceless, fellow mappers. The time of database users is
usually a business expense.
-- Joseph Eisenberg
On Mon, Dec 14, 2020 at 10:44 AM Christoph Hormann
wrote:
Anders Torger hat am 14.12.2020 15:49 geschrieben:
Okay, but why does the OSM-Carto renderer, and all other renderers
kn
Do you have a suggestion of how to map Sweden's highest mountain,
Kebnekaise?
The mountain is called Kebnekaise, it has two peaks, one is called
"Sydtoppen" ("the south peak"), the other "Nordtoppen" ("the north
peak").
Currently it's mapped with the two peaks where one is called
Christoph Hormann wrote:
Anders Torger hat am 13.12.2020 15:28 geschrieben:
So what I've settled for (for now) is as follows:
- same name on each part (the only way to get the data useful *today*)
- a new relation with all parts as members (role unset), type=natural,
natural=wetland, name=
I
e before we introduce a new drawing
rule that makes it more difficult to edit.
/Anders
On 2020-12-14 22:25, Anders Torger wrote:
I certainly agree that we should not waste mapper's time, but in this
case it was mainly actually to make it easier for myself with JOSM to
find my way bac
.
By the way, I've pushed an update of the Rimmjoáphe wetland now, removed
the relation and made a multipolygon to span the river.
On 2020-12-15 09:03, Ture Pålsson via Tagging wrote:
15 dec. 2020 kl. 08:26 skrev Anders Torger :
And about wetlands, couldn't those be just rendered on top of forest
We should probably not have all these possible generalized areas in our
db. Just as we probably shouldn't have a bedrock map in the db either,
at least not until it can manage layers.
But we could simply pick one criteria, document the definition of the
"fuzzy area" and have that. Some
or not.
/Anders
On 2020-12-15 06:22, Ture Pålsson wrote:
14 dec. 2020 kl. 22:30 skrev Anders Torger :
Cool! It would be really nice to see a demo :-)
Rijmmoáhpe renders sort of reasonably now at
http://lab3.turepalsson.se/map . (On the generated PDF, not on the
"slippy map". And it's
pieces, and set the name= and appropriate
natural= and wetland= tags on the relation.
On Fri, Dec 11, 2020, 11:11 AM Anders Torger wrote:
Hello,
I was on this list a while back expressing some frustration over
limitations when tagging nature and thought about getting involved in
a
process
Thanks I'll do it this way then, this actually works and even gets
rendered, although with OSM-Carto it becomes a name tag in each separate
part so not exactly beautiful, but the data is there.
/Anders
On 2020-12-11 18:07, Christoph Hormann wrote:
Anders Torger hat am 11.12.2020 17:07
When I started using JOSM, which is not so long ago, I hated it. If one
is used to graphic software from say Adobe etc, many things in the user
interface feel backwards. But now when I've got into it, one can really
work effectively. When I started I didn't really understand the
multipolygon
bute and grow
the OSM community.
We're all here complaining about computational needs required by rendering
servers, but there are some great vector tile implementations that require
way less computational needs.
Moral of the story: We need Vector tiles.
El El sáb, nov. 7, 2020 a la(s) 05:24,
an import which can be really
technically challenging, which we see the effects in our Swedish map
now).
On 2020-11-08 06:51, Tomas Straupis wrote:
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
not used by
OSM-Carto or any of the big providers.
On 2020-11-08 13:41, Tomas Straupis wrote:
2020-11-08, sk, 12:31 Anders Torger rašė:
To me it seems like an odd "political" design decision to have a
separate database though. Why just not arrange the database in layers,
and this could be
t. But I'm a nice guy
and I don't mean any harm :-). I truly want OSM to succeed globally
*including* Sweden, *and* have great cartography as we expect here, but
I just can't do it on my own.
/Anders
On 2020-11-08 15:09, stevea wrote:
Warning: lengthy reply to an already-lengthy thread.
there to the casual public is
one solid high quality entity,
today it's too fragmented
On 2020-11-08 23:00, stevea wrote:
On Nov 8, 2020, at 7:58 AM, Anders Torger wrote:
I believe the processes available are limited in terms of fixing
structural problems.
You say you have long experienc
A question, is this database only intended for very large polygons, or
also rather small?
From my mapping perspective here in Sweden fuzzy polygons exist down to
say ~1 km size (generally speaking names of hills, valleys, peninsulas
etc). In fact the most I run into is in the 2 - 10 km size.
rick wrote:
On Sat, 7 Nov 2020 at 04:34, Anders Torger wrote:
** Due to limitations in area-based name tagging the map looks empty
just when zoomed out a little, as names disappear almost directly, so
despite detailed mapping and tagging the overview map is not as useful
as it could be. While the re
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"
onger work.
/Anders
On 2020-11-07 07:52, Tomas Straupis wrote:
2020-11-07, št, 00:41 Anders Torger rašė:
However, how important is it that update of the map is immediate for
every database update? <...>
OSM-Carto is a style whose purpose is to visualise OSM data to
MAPPERS, do it quickl
on the rendering process? Could we do a specific and targeted fundraising effort to improve the renderer to make as much use of the limited computer power we have? How much would such an endeavor actually cost and how would one go about organizing that?
On Nov 7, 2020, at 10:36, Anders Torger wrote
it's about the resulting map. The current use of points
won't do what's required to be able to make good cartography.
/Anders
On 2020-11-07 13:01, Frederik Ramm wrote:
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
he product the end user sees.
/Anders
On 2020-11-07 12:47, Tomas Straupis wrote:
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
To make it pleasing the resulting product should be good, and I think
there is more to do there, not the least for rural areas where the
naming issues is most evident.
/Anders
On 2020-11-07 13:30, stevea wrote:
On Nov 6, 2020, at 1:51 PM, Anders Tor
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
the coming years. Personally I prefer the pixel renderings still as
vector is a bit slow on many computers. But it's the future
On 2020-11-07 17:45, Anders Torger wrote:
Here's an example of vector maps for Norway, Sweden and Finland as
presented by a popular Swedish address lookup service:
https
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,
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
ying here is that generalisation (the real one, not DP) will have to
be done anyways as OSM community is starting to see the disadvantages
of legacy raster maps and is getting used to the idea of vector maps
(for the client, not between servers).
2020-11-07, št, 21:23 Anders Torger rašė:
(I had to run it
M is still too a large extent
unmapped or poorly mapped) if despite exact and fully detailed
contributions there will still be sub-standard maps coming out of it.
/Anders Torger
___
Tagging mailing list
Tagging@openstreetmap
I agree, but one renders (in some way at least), the other doesn't.
Which one will the casual mapper choose? I'm a bit impatient and like to
see results now.
The cluster tag was drafted 2015, the group tag 2018. None of them
render as far as I know.
/Anders
On 2020-11-06 23:10, Martin
ould think that some of these algorithms could run on GPU clusters
these days, but I have no idea... it feels a bit problematic though if
the quality of OSM's cartography is held back due to limited server
infrastructure.
/Anders
On 2020-11-06 22:51, Anders Torger wrote:
I'd love to help out if the
of the semantically superior
group, as multipolygon actually renders.
/Anders
On 2020-11-06 23:26, Martin Koppenhoefer wrote:
Am Fr., 6. Nov. 2020 um 23:21 Uhr schrieb Anders Torger :
I have not understood why there are these CPU limits, if it's "just" due to
under-financed server infr
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 route planners (and indeed bike
computers) that use OSM in
On 2020-11-06 23:35, Martin Koppenhoefer wrote:
Am Fr., 6. Nov. 2020 um 23:28 Uhr schrieb Anders Torger :
I agree, but one renders (in some way at least), the other doesn't. Which one will the casual mapper choose? I'm a bit impatient and like to see results now.
The cluster tag was drafted
, but I don't know, as you haven't said.
/Anders
On 2020-12-13 20:37, Christoph Hormann wrote:
Anders Torger hat am 13.12.2020 20:08 geschrieben:
[...] I think to actually have them all
tied together in a unit is still a good idea, [...]
That does not answer my question
Why is the relation problematic (honest question)?
I was starting to think that some sort of naming relation could be the
answer, ie you put both peaks in a relation with for example type=name;
natural=mountain; name=Kebnekaise.
In addition one should write clearly that peak serves dual
Like every Swede I have climbed the mountain, so I do have some local
knowledge :-). There is an arete there, that's correct, but it's not
named. Kebnekaise is the name of the mountain. It's Sami lands, as far
as I understand the names of the mountains came first, then the names of
the peaks
76 matches
Mail list logo
