Re: [Tagging] How to put a name tag on an area with more than one type?

> 14 dec. 2020 kl. 19:06 skrev Ture Pålsson : > > I have implemented the merge-adjacent-areas scheme in my renderer. I’ll try > to get a demo up… :-) > > Having said that, as a renderer implementer, I have a slight preference for > the relation method. It is s implyeasier to join things on

Re: [Tagging] The saga of landuse=reservoir vs water=reservoir

> 16 dec. 2020 kl. 17:25 skrev Tomas Straupis : > > What about maps made according to Cartographic conventions? > You know, something on the lines of: https://map.geo.admin.ch > Would > it be possible to make maps of such quality writing general queries > like

Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-15 08:48 Anders Torger a écrit: However I'll soon go through these edits again and then I will add multipolygon for the split, and if your renderer takes that into account we should end up with a single multipolygon. I think in the case of Muddus it will work in all cases, ie we

Re: [Tagging] How to put a name tag on an area with more than one type?

2020-12-15 23:38 skrev Martin Koppenhoefer: Take a look back what I mentioned 3 days ago in my first answer: "...If we want to map all those "meta areas" with names we would do well to think about additional ways of delimiting space (i.e. different kind of geometry objects), e.g. a fuzzy

Re: [Tagging] How to put a name tag on an area with more than one type?

> 15 dec. 2020 kl. 08:26 skrev Anders Torger : > > And about wetlands, couldn't those be just rendered on top of forests so we > didn't have to make these complex multipolygons? It does make sense to have overlapping wetland and forest, though. To take a swedish example: down here in 08-land

Re: [Tagging] How to put a name tag on an area with more than one type?

> 15 dec. 2020 kl. 08:26 skrev Anders Torger : > > And about wasting mapper's time. What about that we have to punch holes and > make river areas for rivers nowadays? Punch holes for waters in forest areas? Anecdote: When I first started toying with rendering about ten years ago, I had

Re: [Tagging] How to put a name tag on an area with more than one type?

> 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 a bit hard to find, since

Re: [Tagging] How to put a name tag on an area with more than one type?

> 14 dec. 2020 kl. 19:06 skrev Ture Pålsson (that’s me!): > > I think it would be good to keep the set of possible values for the ’type’ > tag small, so I’d like to propose another level of indirection; something like > > type=named_area, named_area=natural, natural=wetland, name=Peter’s

Re: [Tagging] How to put a name tag on an area with more than one type?

14 dec. 2020 kl. 15:49 skrev Anders Torger : > > Okay, but why does the OSM-Carto renderer, and all other renderers known to > man(?) make multiple text labels then, when it should be a single one? Look > at the result, it looks horrible. Do you really think this is the way it > should be

Re: [Tagging] How to put a name tag on an area with more than one type?

> 13 dec. 2020 kl. 16:15 skrev Christoph Hormann : > > I am trying to understand what the issue is with the recommendation for > mapping you have received from multiple sides here. Just to clarify, could you summarise what that recommendation is, for the Rijmmoáhpe case? The thread has become

Re: [Tagging] How to put a name tag on an area with more than one type?

> 13 dec. 2020 kl. 15:21 skrev Paul Allen : > > I'm probably misunderstanding this, but torp doesn't seem to be a type of > building. The tag building=torp says that this building IS a torp (as > opposed to a house, or a shop, or a garage, or a shed, or a barn). > If you feel a need to

Re: [Tagging] How to put a name tag on an area with more than one type?

> 13 dec. 2020 kl. 11:40 skrev stevea : > > Thank you, Ture: an excellent example and a great brief overview. From my > perspective (if I were more of an OSM beginner), I might ask about the > example of "torp:" might creating a tag like building=torp seem like it's on > a good track?

Re: [Tagging] How to put a name tag on an area with more than one type?

> 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 as well. Around where I live

Re: [Tagging] coastline v. water

By the way, an... amusing test case for all things related to water and label placement is Lake Mälaren, the lake that Stockholm is separating from the sea, and all its (named!) nooks and crannies: https://www.openstreetmap.org/relation/1433877 . I've had at least 3 different bits of it poking

Re: [Tagging] coastline v. water

I mentioned the problem of mapping "fuzzy" areas to a friend, who replied along the lines of "why, of course such areas should be mapped as functions, taking a point as input and returning a real between 0 (definitely outside) and 1 (definitely inside)!". I'd rather not have to implement

Re: [Tagging] Basic cartography features missing, why?

> 6 nov. 2020 kl. 19:31 skrev Anders Torger : > > Hello everyone, newcomer here! > Only marginally related to the discussion, but: For Sweden, you may want to look at the rendering at http://lab3.turepalsson.se/map/ (the generated PDF:s, not the tiles;

Re: [Tagging] PTv2 public_transport=stop_position for stop positions that vary based on train length

Here in Stockholm, trains seem to line up one end of the train with one end of the platform. Usually, that's the end where the entrance is, but sometimes there are entrances at both ends, so if you arrive just in time at an unfamiliar station and find that it's a short train, you may be in for

Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

> 27 maj 2020 kl. 12:42 skrev Volker Schmidt : > > > > […]how to indicate that a path is a hiking trail. It has been proposed to > introduce a new value path=trail or path=hiking for that purpose. > As we do already have the sac_scale tagging for level of difficulty of hiking > paths and

Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

> 27 maj 2020 kl. 06:54 skrev Yves : > […] > I'm as fool as you, and always mapped the paved, urban-style as > highway=footway and the ones in the wilderness as highway =path. > So have I, and so have, as far as I can tell from the areas I am familiar with, most mappers in Sweden. Not all

Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

26 maj 2020 kl. 11:33 skrev Volker Schmidt : > > We have now been reviving the path discussion in 73 messages, and counting ... > I still feel we are not understanding each other (or is it only me who is > lost?) > To me a highway=path is a concept that is well defined in the wiki, and the >

Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

> 22 maj 2020 kl. 17:25 skrev Andy Townsend : > > I think that there's another problem with the standard style as well - aside > from surface rendering it's hugely biased towards urban centres. Looking at > https://www.openstreetmap.org/#map=13/53.9023/-0.8856 you can't see any paths > at

Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

> 22 maj 2020 kl. 12:52 skrev Daniel Westergren : > > […] Then there is width, which is only tagged on 3.5% of highway=path. I was > discussing width of paths in another forum. For a forest path, would you say > width is measured as the actual tread on the ground only? For a runner and > MTB

Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

21 maj 2020 kl. 09:21 skrev Daniel Westergren : > > Expanding on the discussion about attributes for trails. What's the current > status of the highway=path mess? OSM is increasingly becoming more useful for > forest trails than for car roads (for which other sources are usually more >