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 s
I think is fair or not I need to change the style or just back off.
It's not that easy though when being 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
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 h
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 dis
meaning
"here 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 m
normal, or is the 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
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 m
rives to be... I'll think
about 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 lo
/Anders
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 curren
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 whe
ready to
accept that. There's no use to map areas which we never 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 ha
more than they could before and are more 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. Mayb
we need to relate to for all OSM tags and
features.)
/Anders
On 2020-12-21 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. A
due to the speckled and diffuse character 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 na
quot; would suit perfectly
well, and is already in existence, but it needs rendering in OSM-Carto
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, n
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?
Plateau
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 rand
parts together 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 natu
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 co
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 criteri
and=swamp".
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
s correctly represented 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
&qu
ot;not wasting mappers' time", we should surely look
into ease of editing, and think twice 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,
makes me think 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 wh
27;t make life harder for mappers to save the
database users a few CPU cycles.
Your time 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
e missing and on top of that get
on this list and see the lack of interest and/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, an
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 with the
cean is, and renderers should consider drawing a label".
Note that this is not "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
ll 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
they're bad I'll remove the
relation. I 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 wr
usage recommendations
so mappers actually 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 si
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: "mak
ly are is an example of fuzzy areas 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 bo
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
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 purpo
ported sufficiently
well, 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, [...]
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 ca
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=
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 "Kebnekaise
ed, or a
specialised type can be defined.
I would think a pilot project could test the concept 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 whi
/Anders
On 2020-12-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
[2] https://wiki.openstreetmap.org/wiki/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 i
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 fi
ions like them which
aren't (like those tagged boundary=*), independently as far as
renderers are 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 ren
to have a map that doesn't support them (and say that
we only intend 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
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 extent
hat the method I choose 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 qu
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, as
with the discussed case is 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
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
of the wetland 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
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
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. I
n't need to be too afraid to compete with the
commercial providers
** It's important for OSM success that 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
to Tomas I suppose)". But I just don't have that capacity, and
the alternative would be to just shut up and continue not knowing what's
going on, so I chose to stir in the pot a little bit. But I'm a nice guy
and I don't mean any harm :-). I truly want OSM to succeed glo
che feature 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
realize
that there's a lot more data than just the raster images displayed by the
standard tile layer, than they will be more likely to contribute and grow
the OSM community.
We're all here complaining about computational needs required by rendering
servers, but there are some great
r best attempts of making 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 hav
ver produce a tile that large. What I'm
saying 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-
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 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,
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
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
butor here do it as a sort of pleasing handicraft.
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, ste
ion today, and that it's free with open license
unfortunately doesn't mean much here. The only thing that means
something is the 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 ho
e end 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 render
sing 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 the limited computer power we have? How much would such an endeavor actually cost and how would one go about organizing that?
ome things that need to start moving, and
for some of these things the old processes no longer 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? <...>
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
hat the official
maps can show.
On 2020-11-06 23:22, Graeme Fitzpatrick 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
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 w
lygon instead 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-fi
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 Kopp
s a layman one
would 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 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
that from the government data. With OSM it
seems... ehh... complicated. I'm not really prepared to significantly
increase my mapping effort (Sweden in OSM is still too a large extent
unmapped or poorly mapped) if despite exact and fully detailed
contributions there
76 matches
Mail list logo
