On 30.09.2018 05:00, Bryan Housel wrote:
> From my own perspective as the main developer on the main editor for
> OSM,
This is way too exaggerated. While iD is most visible, most data is
created not by iD. And it is not always possible to advice novice user
to use iD. For example iD only
2018-09-30, sk, 17:09 Christoph Hormann rašė:
> Note this is a completely wrong characterization of the water=* tagging
> scheme that is playing on nationalistic sentiments. You should not do
> that.
Sorry, had no intention to insult anybody.
This alternative scheme _originated from Russia_
2019-01-10, kt, 09:06 Martin Koppenhoefer rašė:
> coding the geometry into the db does not necessarily mean creating polygons
> though.
> You could also store just 3 nodes and a hint that these are representing a
> polygon, to store a triangle (for example).
Sorry, I did not get it. How
2019-01-09, tr, 19:36 Mateusz Konieczny rašė:
>> And here we're one more step closer to introducing gis layers in OSM.
>
> I have no idea how natural=peninsula tagging is related to that.
In order to have correct labelling you need polygon geometry for
peninsulas (as well as for other objects),
2019-01-10, kt, 10:54 Dave Swarthout rašė:
> We just went through a whole discussion about mapping bays as
> polygons. (see
> https://lists.openstreetmap.org/pipermail/tagging/2018-November/040911.html)
> <...>
Yes, I agree with everything. You are describing why polygons are
needed for
And here we're one more step closer to introducing gis layers in OSM. Not
there yet, but as maps created from OSM data start aproaching cartographic
conventions, the only other way is to use other - non OSM sources.
___
Tagging mailing list
I would agree with those stating importance of road network hierarchy and
connectivity (for both routing and cartography).
Having unclassified as higher than residential but lower than tertiary
helps a lot.
Maybe google will translate this old post with some practical examples and
some technical
2019-02-20, tr, 20:08 Florian Lohoff rašė:
> From the original meaning unclassified was the lowest class road in
> rural or off city limits. residential was the lowest class road within
> city limits. (Assuming that city limits mean residential usage)
unclassified "original" meaning was "for
Some time ago I was proposing to introduce topology rules, at least
locally. Those (besides a lot of other stuff) would cover which
polygons can be above which polygons, which polygons can not be above
which polygons etc. Such rules are already used for years in Lithuania
in regards of forests.
2019-02-11, pr, 16:26 Ture Pålsson rašė:
> That possiblity already exists, as tree_lined=*. However, I believe tree
> rows sometimes appear on their own. For example, the tree row in this
> picture (which was in the side bar of the Wiki for natural=tree_row)
> looks like it is not lining anything
2019-02-11, pr, 11:29 Ture Pålsson rašė:
> As someone who tries to render smallish-scale (typcally 1:25000 or
> 1:5) maps from OSM data, I am always slightly annoyed when someone
> states that something does not need to be mapped bacuse it can be
> inferred algorithmically from other data,
Hello
landuse=reservoir is from original OpenStreetMap water tagging scheme.
water=reservoir is the newer one ("all blue is natural=water") with
no advantages over previous one. Original (landuse=reservoir) is still
more prominent even with Mapbox/iD's aggressive push for the later
one.
> I find very strange that reservoir is a landuse by itself
> it would be a bit like putting landuse=rest on a bench
> or landuse=stop on a parking lot.
> <...>
There are a infinite number of arguments on both sides. Pandora box
was already opened and dual standard for water tagging already
2019-07-03, tr, 08:04 Mateusz Konieczny rašė:
> 2) Take the leading sentence mentioning Solid/Soft out of the tracktype
> description (or de-emphasize it)
> I am dubious about redefining extremely
> popular tags. <...>
How come? You are pushing the changing of entire water tagging schema!
2019-07-08, pr, 10:53 Márton Keleti rašė:
> I consider using highway=path on urban shared cycle/footways a very bad an
> confusing practice. <...>
Idea is that path is not only "one man width unpaved" way, but it is
also a way where neither footway, nor cycleway fits because the way is
for
And here the idea of a new separate data layer (as in GIS) for geometries
of fuzzy features rises again...
Waiting for its time.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Hello
Road hierarchy is needed for a number of things:
* deciding which classes of roads to display on different scales in a map
* performing road network validation
* other tasks (f.e. typification of buildings - orientation)
Hierarchy would be different in different context:
2019-08-04, sk, 11:32 Florian Lohoff rašė:
> For me unclassified is the same as residential. <...>
Ok, so unclassified vs residential is regionally defined, as I wrote.
But what about service/track?
___
Tagging mailing list
> Personally, I'd have put residential / living together above unclassified
Interesting. Unclassified was always (more than 10 years) defined
for "through traffic" which puts it a higher in a hierarchy. From what
I understand it was always in the group of primary/secondary/tertiary
just the one
Let's say we have a residential road R. Going out of this residential road
there is a way A into the neighbouring residential area (say 50m length).
Out of that way A there is anower way B leading into the fields/forest
which lies outside of the residential area. B way is long enough and
2019-08-04, sk, 11:56 Erkin Alp Güney rašė:
> Paved: service unpaved:track
service could always be paved and unpaved.
track used to be always unpaved, but somewhere somehow tracktype1
became paved :-)
___
Tagging mailing list
All right, let's make it more detailed and more extended.
R
R
RAAA
R A
R
R
R
R
Now A and C are ways leading into the inner territory of residential
building(s). But A has another important road B getting out of it, and
C does not. Which means A has through traffic while C does
2019-08-04, sk, 12:59 Florian Lohoff rašė:
> If B is a public road A cant be private property and thus not be
> a service. If B is a track A can be a service because both
> of them share the concept of not beeing for the general public.
>
> Or vice versa. If you make A a service B cant be a public
Well, I would be reluctant to tag the ways leading to this remote
house as unclassified or residential:
https://openmap.lt/#h/17.01/54.19809/24.27953/0/0/
These are public ways/roads, anybody can use them - they are not
private. Yet they are not in the database of Lithuanian road agency,
so they
2019-09-30, pr, 10:35 Martin Koppenhoefer rašė:
>> topo map, or ask virtually any local 'what mountain is that big one?'
>> while pointing, and you'll get an answer, but for many of these peaks
>> I don't think I've ever seen a sign with the name, so I've been told
>> that in such a case the name
2020-01-28, an, 20:15 Jmapb rašė:
> Thanks for the background. Looks like Richard Fairhurst already reverted the
> "shared foot/bicycle must be path" assertion on the cycleway=* page. J
Yet for ten years or even more the logic was that if the same way is
designated for both pedestrians and
Why would you want to "force" using more than one class for meadows
when absolute majority of maps will not need more that one class?
--
Tomas
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
2020-03-15, sk, 08:53 Warin rašė:
> There is no real 'force' on a mapper to do anything. If a mapper chooses not
> to use the subtags then they don't have to.
landuse=meadow was mention together with natural=grassland etc. If
it is only about subtags meadow=* - I'm fine with that.
> Similar
2020-05-23, št, 04:51 Jarek Piórkowski rašė:
> See also: not rendering roads or hamlets in very sparsely populated
> areas because we have one map style which needs to accommodate central
> European densities.
OSM-Carto is a very well done DATA VISUALISATION. It is not a
cartography. What
> Very well put! If I understand correctly, to do this without heavy
> pre-processing,
> the information would have to be in the tags?
> Would it have to be in the tags of every individual way, or would a tag on
> an encompassing area (e.g. landuse=residential) be sufficient?
Correct.
2020-07-21, an 13:15, dktue rašė:
>
> So why can't the wiki state: "If you tag, then please do so using
> waterway=riverbank" (as this is preferred by the *community*)?
>
There is no way to calculate the "opinnion" of the community and
authoritarian/dictator attitude of iD coders and lack of
2020-07-21, an, 11:20 dktue rašė:
> Why do we need both variants and why don't we just say that
> waterway=riverbank is preferred?
There is an original OpenStreetMap water schema with lakes as
natural=water, reservoirs as landuse=reservoir, riverbanks as
waterway=riverbank etc. It is a
2020-07-21, an, 15:17 Mateusz Konieczny via Tagging rašė:
> Because despite claims mentioned above - there are also people preferring the
> second schema,
> it is not case of "iD developers vs community" like it is/was with some case.
Situation when there are no barriers to changing widely
2020-07-21, an, 15:00 Mateusz Konieczny via Tagging rašė:
>> It is totally NERDY.
> What you mean by that?
There are two very different things:
* IT
* coding
IT considers wider/higher-level things like stability, quality of
the final product, documentation, usability etc. etc. IT
2020-12-17, kt, 00:02 ael via Tagging rašė:
> This is slightly off-topic in that I am picking up on the
> hazard tag rather than rapids. I see no objection to adding hazard=rapids
> although that might be redundant unless there exist rapids that are
> not hazardous. I suppose shallow rapids might
2020-12-17, kt, 18:20 Joseph Eisenberg rašė:
> That's not accurate, Tomas.
Why? Mateusz without the end of discussion started, well continued
editing the wiki (I had to correct some of his misinterpretations
which have been discussed here), he also made some attempts in JOSM
trac, these are
2020-12-13, sk, 20:09 Mateusz Konieczny via Tagging rašė:
> 2020-12-13, sk, 19:18 Mateusz Konieczny via Tagging rašė:
> Mateusz, can you point out which of my claims is a lie?
>
> "iD coders decided to skip standard IT processes of product development
> (or were not familiar with the basics of
2020-12-13, sk, 16:13 Brian M. Sperlongano rašė:
> 2019 was a turning point, and over the last two years, landuse=reservoir has
> been on a steady decline, while water=reservoir continued its rapid growth.
New/duplicate schema with water=reservoir only launched because iD
coders decided to skip
But prudent way would probably be to come with some rules on change of
tagging schema. Like:
* When tagging schema is too widespread to be protected against changes
* What benefits should new schema add in order to deprecate existing schema
Because otherwise this plague of deprecating existing
2020-12-13, sk, 19:18 Mateusz Konieczny via Tagging rašė:
> New/duplicate schema with water=reservoir only launched because iD
> coders decided to skip standard IT processes of product development
> (or were not familiar with the basics of IT) and simply went for what
> they personally liked, not
2020-12-13, sk, 18:58 Brian M. Sperlongano rašė:
> Let's please assume good faith and be respectful while we discuss
> differences of opinion with an open mind - we are all here for the
> same reason - working together to create the best possible map for the world.
I do agree that sometimes I
2020-12-21, pr, 01:10 Clifford Snow rašė:
> Please refrain from calling out others as outlined in the Etiquette
> Guidelines [1]
Can you be more specific?
___
Tagging mailing list
Tagging@openstreetmap.org
2020-12-21, pr, 11:02 Volker Schmidt rašė:
> Mass deprecations are counter-productive in general and independently of
> whether they the new tagging is better in some way..
+1
___
Tagging mailing list
Tagging@openstreetmap.org
2020-12-21, pr, 15:54 Anders Torger rašė:
> A local renderer would be limited in use <...>
Not necessarily ;-)
1. It could be a practical/visual proof of a "better way".
2. It could be a testing ground for finding solutions to some
international (wider than OSM, say ICA) cartographic
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 strives to be...
We are ALL OSM community. If somebody tells you that "I am OSM and
only A is right" - do not believe them.
YOU define what OSM is and where it
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 landscape -- also work as an end
2020-12-16, tr, 18:58 Ture Pålsson via Tagging rašė:
> Could you elaborate a bit on what cartographic features on that map are
> possible or impossible with the different reservoir tagging schemes?
Symbolisation (colour), selection (different classes for different scales).
In other maps
2020-12-16, tr, 20:30 Kevin Kenny rašė:
>> https://upes.openmap.lt/#17/56.296411/22.330154
> Looks good, I think... but what is the tagging?
waterway=rapid
At the time of usage it was deprecated (and plural), but I know what
that means and after each discussion on tagging list I'm less and
> If you believe that your argument in favor of tagging reservoirs as landuse is
> strong, then you should have no objection to placing this question up for a
> community vote, and allowing the community the freedom to decide.
Brian, landuse=reservoir is the ORIGINAL and ACTIVE schema. Why
2020-12-16, tr, 19:44 Kevin Kenny rašė:
> With respect to water, another concern of mine is that our tagging schema
> does not
> offer any way to tag that there are rapids in a river without knowing how to
> grade the
> difficulty of a canoe or kayak run.
Why? Cayaking info is pretty rare -
2020-12-16, tr, 20:03 Kevin Kenny rašė:
> Many smaller reservoirs have artificially hardened shorelines completely
> surrounding them, which could be why you thought that the symbology
> distinguishes 'lake' from 'reservoir.'
This might be correct. I guess it depends on direction you look at
> I get that you consider benefits of natural=water water=* schema
> as unimportant
Can you LIST the benefits? As you see them TODAY. So that we could
evaluate/compare?
(Not point to proposal on wiki, as largest part of it never materialised)
___
2020-12-16, tr, 16:01 Mateusz Konieczny rašė:
> https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dreservoir#water.3Dreservoir
> (just added)
Thank you. Maybe it is better to discuss here before adding to wiki?
My arguments on the points you've added:
1. Regarding benefit of having a
2020-12-16, tr, 17:04 Mateusz Konieczny via Tagging rašė:
> I agree that it is useful only for primitive rendering of water areas
> (that possibly filters water areas by area but does not distinguish
> between lakes and rivers). It may be worth mentioning.
>
> But it is also the most typical and
2020-12-16, tr, 01:32 Brian M. Sperlongano rašė:
> The iD editor preset appears to use water=reservoir while the JOSM
> preset appears to use landuse=reservoir.
Not entirely correct.
* JOSM gives freedom to mappers and supports BOTH.
* iD forces to use water=reservoir and evenmore pushes
Brian, you're using statistics which DO NOT represent mappers preferences.
If you would use only JOSM created objects - then it would be close to
mappers preferences (as JOSM allows mappers to choose).
But you use iD created/adjusted objects and as it does not allow
showing your preference
2020-12-16, tr, 17:19 Brian M. Sperlongano rašė:
> The statistics reflect all areas, regardless of which editors were used to
> create them.
> I stand by them, as numbers do not lie.
Have you heard of the saying "correlation is not causation"?
You have to understand where numbers come from
2020-12-16, tr, 18:04 Mateusz Konieczny via Tagging rašė:
> Then I can you show some map style that do it differently and
> render all types of water areas in the same way (some
> render also labels in the same way, with exception
> for linear features)
BTW. It is another advantage of
2020-12-16, tr, 18:04 Mateusz Konieczny via Tagging rašė:
> Then I can you show some map style that do it differently and
> render all types of water areas in the same way (some
> render also labels in the same way, with exception
> for linear features)
>
2020-12-21, pr, 17:47 Brian M. Sperlongano rašė:
> The current data model works just fine for fuzzy areas: it requires a polygon
> combined with tagging that indicates that the area is "fuzzy". Since the
> current
> data model allows both polygons and tags, fuzzy areas could be mapped just
>
2020-12-13, sk, 20:41 Mateusz Konieczny via Tagging rašė:
> Following outcome of approved proposal that you dislike
> is not indicator of not following
> standard IT processes of product development.
Following some wiki page (which states that landuse=reservoir is not
deprecated) written by one
2020-12-20, sk, 17:59 Paul Allen rašė:
> Too late, at least for iD. Its authors have already decided to deprecate
> landuse=reservoir. All this proposal does is document the fact.
Strange sequence/logic tho:
1. iD brakes the rules, does something contrary to what
OpenStreetMap/mappers do,
And while we're discussing here, Mateusz is already on a rampage to
change wiki pages, write patches etc. Thus buldozzing his opinion,
ignoring others. Showing "community building" behaviour.
___
Tagging mailing list
Tagging@openstreetmap.org
2020-11-08, sk, 09:46 Mateusz Konieczny via Tagging rašė:
> (and it is from person who put a lot of effort into tagging improvements,
> wikifiddling,
> deprecating some unwanted values, deduplication and validator-related work
> and has
> some experience from data consumer side)
That is a
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?
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 a separate layer? From a technical perspective I
> suppose it wouldn't have to be layers as
2020-11-08, sk, 19:54 Joseph Eisenberg rašė:
> The reason is that at mid zoom levels there is far too much data
> in the database for it all to be made available in a vector tile
> format so that the map is fully customizable.
Unless we will do a real generalisation which would mean we will
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 quickly (fast feedback is essential). OSM-Carto also
has a requirement
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
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
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
2022-10-23, sk, 22:31 Brian M. Sperlongano rašė:
> I agree that there is a set of "core" tags whose meaning is so widely
> understood
> and established that they are standard tags by usage and convention today. For
> the case of these "core" tags, I'm not sure what value we would add by
>
72 matches
Mail list logo
