[OSM-talk] OpenStreetMap Carto release v5.7.0

[Paul Norman]

Dear all,
Today, v5.7.0 of the OpenStreetMap Carto stylesheet (the default
stylesheet on the OSM website) has been released. Once changes are
deployed on openstreetmap.org it will take couple of days before
all tiles show the new rendering.
Changes include
-Unpaved roads are now indicated on the map (#3399)
-Country label placement improved, particularly for countries in the
  north (#4616)
-Added elevation to wilderness huts (#4648)
-New index for low-zoom performance (#4617)
-Added a script to switch between script variations for CJK languages 
(#4707)

-Ordering fixes for piers (#4703)
-Numerous CI improvements
Thanks to all the contributors for this release, including wyskoj, 
tjur0, depth221, SlowMo24, altilunium, and cklein05, all new contributors.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v5.6.2...v5.7.0
As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Minh Nguyen]

Vào lúc 00:59 2023-01-03, Simon Poole đã viết:
Not quite unexpected this discussion has already gone off on a tangent 
about stable ids. My question on the other hand would be: what do you 
actually want to achieve and what would you expect an application to do 
with the parameter?


Furthermore, would these goals align with the goals that the IETF laid 
out for the geo: URI scheme in RFC 5870?


* Compact
* Simple
* Human-readable
* Protocol-independent

An OSM element ID is compact, and a number is simple. But an element ID 
by itself is neither human-readable nor protocol-independent. This 
sounds more like a proposal for a new URI scheme that happened to latch 
onto geo: because it's also about geography.


While I think it would be an uphill battle to convince the IETF that OSM 
is important enough to have its own standard URI scheme, it would be 
much more feasible to register a URN namespace under the urn: scheme. 
For example, node 8330986510 could be .


You could think of it as the machine-readable analogue to how mappers 
often refer to "node 8330986510" in the middle of a sentence. It would 
allow software to decide whether to resolve the URN as:


https://www.openstreetmap.org/node/8330986510
https://www.openstreetmap.org/api/0.6/node/8330986510
https://nominatim.openstreetmap.org/ui/search.html?q=n8330986510
etc.

A formal, keyword-like URN namespace can be registered with IANA as long 
as it meets some requirements. [1] It needs to have organizational 
backing, which sounds like a role for the OSMF or one of its working 
groups. A given URN would need to be stable: for example, if one refers 
to a particular restaurant in Medellín, then the restaurant can close 
and be deleted in OSM, but the URN can never refer to a barber shop just 
because a mapper repurposed the OSM node to represent the barber shop 
across the street.


IANA also accepts informal, sequentially numbered namespaces that aren't 
subject to these constraints. For example, there's an informal namespace 
for Wikitravel, which uses Wikitravel article names (just as stable as 
OSM Wiki article names) as the identifier string following the 
namespace. [2] Someone would just need to write up an application and 
send it to IANA, but I suspect it still need to convincingly answer the 
question, "What for?"


[1] https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml
[2] https://www.iana.org/assignments/urn-informal/urn-6

It should be noted that we already have a couple of URI schemes in use 
for OSM based tools/editors, and naturally the website object/element 
browsing support.


Simon

Am 02.01.2023 um 18:57 schrieb Sören Reinecke:


Hey,

It came into my mind to get IETF to standardize a parameter explicitly 
linking to osm objects with their corresponding type and id.


The 'geo' URI scheme is standardized as RFC 5870 
 with examples of usage 
. It allows us to 
link to geospatial ressources from web pages or applications 
supporting URI schemes in general. It allows (web) developers to 
direct their users to their map browser of use e.g, Organic Maps, 
Google Maps, Apple Maps, ... The official osm.org makes use of this 
specification in the "share" feature already. Currently it only 
supports linking to geospatial ressources by their coordinates and not 
some id. As OpenStreetMap is playing an important part in the 
geospatial world, the OSMF should try to get IETF convinced.


See registered URI parameters in the 'geo' URI scheme:
'geo' URI Parameters registry at IANA.org 



Our own parameter could have the following syntax:

osmid=(N|W|R)


What do you think?

Greetings

Sören Reinecke


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


--
m...@nguyen.cincinnati.oh.us



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Snusmumriken]

On Tue, 2023-01-10 at 08:39 +0100, Yves wrote:
> 
> 
> Le 10 janvier 2023 08:12:43 GMT+01:00, Snusmumriken
>  a écrit :
> > On Mon, 2023-01-09 at 23:06 +, Andy Townsend wrote:
> > > On 09/01/2023 20:17, Snusmumriken wrote:
> > > > On Mon, 2023-01-09 at 08:21 -0500, Greg Troxel wrote:
> > > > > You seem unwilling to understand that defining a way to refer
> > > > > to
> > > > > ids
> > > > > will cause social pressure not to change ids,
> > > > Is there actually evidence that would corroborate this claim?
> > > 
> > > There have definitely been complaints to the DWG when people
> > > "resurrect" 
> > > old long-deleted nodes, or exhibit "unusual mapping behaviour"
> > > such
> > > as 
> > > never deleting any nodes, and always re-using them in some other 
> > > feature.  There have also been complaints about changes to
> > > objects
> > > that 
> > > people consider "special" such as
> > > https://osm.mapki.com/history/node/1 
> > > and, er,
> > > https://www.openstreetmap.org/node/69#map=17/48.06733/12.86258 .
> > 
> > Right, I guess one could say that when it comes to retaining
> > existing
> > osm ids there is bad practice and good practice, and a grey area.
> > Any
> > proof or indications that creating a URI scheme would increase the
> > bad
> > practice?
> > 
> No, adding such a URI scheme wouldn't change at all the way
> contributors contribute.
> 
> However it would further degrade the impact of the "bad practice". 

Could you elaborate?



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk-fr] Prochaine réunion OSM-FR - ce soir - mardi 10 janvier 21h.

[Frédéric Rodrigo]

Bonjour,

La prochaine réunion de l'asso est prévu pour ce soir

|https://osmvideo.cloud68.co/user/fre-aux-yuh|

Ordre du jour complétable

https://annuel.framapad.org/p/N_IDAQXYLHswlpU2s3oE


Frédéric.



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr