Re: [Talk-GB] Landuse between fences?

[Martin Wynne]

On 01/01/2020 05:11, Warin wrote:

I would map the area around the road as

landuse=highway.

I would do the same for the lane/track between farm fields, while it 
supports the use of the farm it is not a field.


Thanks, but the problem is that landuse=highway is not a valid tag. 
Voting on it was suspended in 2013 after several votes against, see:


 https://wiki.openstreetmap.org/wiki/Proposed_features/landuse%3Dhighway

However, I have discovered that highway=track, *area=yes* is valid - as 
evidence of that it is rendered on the standard map as a light brown 
infill between the fences with the existing highway=track as a routable 
way superimposed over it, in darker brown.


It seems odd to have highway=track twice, but if that's what it takes to 
have a meaningful mapping for an area of land, I'm happy to do it that 
way. Presumably the developers of the standard map know what they are doing.


So I seem to have answered my own question, thanks all for the replies.

cheers,

Martin.

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

Re: [Talk-GB] Landuse between fences?

[Warin]

On 01/01/20 12:20, David Woolley wrote:

On 01/01/2020 00:49, Dave F via Talk-GB wrote:
I was trying to intimate, *personally*, I wouldn't bother obsessing 
with mapping every *square inch* of land.


I also don't think you should be mapping in that detail, but if you 
really want to, I would suggest that you map the wide area with just 
landuse, and then do nested mappings of the fields, with the crop, 
etc., type as well.


Similarly, I wouldn't want a residential estate broken up by road 
corridors.


David some want to map in a lot of detail. So .. let them.

The  road in front of my home has a verge. If pushed I would say that is 
landuse=highway as the verge is used, or should be, for foot traffic and 
to provide some safety from motorised transport.


While the road and verge are there to support the residences 
(landuse=residential) I would map the area around the road as 
landuse=highway.


I would do the same for the lane/track between farm fields, while it 
supports the use of the farm it is not a field. Hair splitting. I don't 
actually map to that detail. I have mapped a few farm fields .. and left 
the lane/track areas blank at this stage. I will go back and map in the 
access driveways to the house but I will leave the rest .. if someone 
else wants to do them .. fine.




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

Re: [talk-au] Delivery Status Notification (Failure)

[Graeme Fitzpatrick]

& done!!!

& funnily enough, after all those listings in Melbourne, the one I got with
8 to go, & which said we were finished when I saved it, was in Mildura!

Thanks

Graeme

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

Re: [Talk-GB] Landuse between fences?

[David Woolley]

On 01/01/2020 00:49, Dave F via Talk-GB wrote:
I was trying to intimate, *personally*, I wouldn't bother obsessing with 
mapping every *square inch* of land.


I also don't think you should be mapping in that detail, but if you 
really want to, I would suggest that you map the wide area with just 
landuse, and then do nested mappings of the fields, with the crop, etc., 
type as well.


Similarly, I wouldn't want a residential estate broken up by road corridors.

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

Re: [Talk-GB] Landuse between fences?

[Dave F via Talk-GB]

Yes I *know*, Martin

I was trying to intimate, *personally*, I wouldn't bother obsessing with 
mapping every *square inch* of land.
Each to there own, of course, map as you see fit, but I find most 
renderings of areas obscure thin centre lines.
Adding surface tags enhances the opacity of tracks/footpaths o the 
'standard' rendering.


On 31/12/2019 18:45, Martin Wynne wrote:

On 31/12/2019 18:10, Dave F via Talk-GB wrote:

I would add the appropriate surface=* tag to the way.


Thanks Dave.

But a way is a *line*.

I want to tag the *area*. I've got 3 ways - 2 fences and a track. 
Tagging ways is easy. Finding a meaningful tag for areas seems to be 
much more difficult.


If the landuse is the same on both sides, a field of cabbages on the 
left and a field of potatoes on the right, I can just let "farmland" 
flow across the track area. But if it is a wood on the right, where is 
the boundary between the wood and the cabbages? The track? Stitching 
things to highways is frowned on. Or one of the fences? Which one?


cheers,

Martin.


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



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

Re: [OSM-talk-fr] Défusion de commune

[Donat ROBAUX]

Ca y est c'est fait. Vous m'excuserez de l'avoir fait en 3 changeset, mais je
voulais faire ca propre:
https://www.openstreetmap.org/changeset/79071173
https://www.openstreetmap.org/changeset/79071176
https://www.openstreetmap.org/changeset/79071178

Vous avez le droit de jeter un œil pour voir si c'est bien fait. Pour
l'ancienne "commune nouvelle", à voir si on laisse comme ca ou pas. La
situation est peu fréquente. Je ne sais pas ce qui a été fait pour les
autres cas qui se sont présentés.

On va pouvoir faire un tweet en disant qu'on est les seuls à jour!

Donat



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] Défusion de commune

[Philippe Verdy]

La date c'est surtout pour les élections municipales, il fallait que ce
soit fait avant la clôture des listes électorales (espérons que les
inscriptions de dernière minute ou cette année aient bien précisé la
commune d'inscription, sinon il va y avoir un peu du boulot en janvier pour
réviser en tenant compte des adresses des nouveaux inscrits, avant l'envoi
des cartes d'électeurs en fin janvier ou début février, au moins 1 mois
avant le scrutin et pour les dépôts de candidatures). Les listes ne peuvent
normalement plus être touchées le 1er janvier. Ces derniers jours depuis
l'arrêté qu'elles ont du recevoir en urgence, la commune a du s'atteler à
contrôler ça mais elles ont un mois pour finaliser leurs listes et les
faire certifier et déposer en préfecture.

Le mar. 31 déc. 2019 à 20:48, Donat ROBAUX  a écrit :

> Hello,
>
> J'ai bien fait de regarder le 20h de TF1. Il est question de la défusion de
> commune de Saline (14). Donc chaque commune repart chez soi: Troarn et
> Sannerville au 1er janvier.
>
> Le 28 décembre, le tribunal administratif de Caen a annulé l’arrêté
> préfectoral portant sur la création de la commune nouvelle de Saline, à
> compter du 31 décembre 2019 (pour que les décisions prises depuis la fusion
> ne soient pas caduques). À cette date, Sannerville et Troarn redeviendront
> deux communes distinctes.
>
> Donat
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-nl] OSGeo.nl/OSM-NL/QGIS-NL Nieuwjaarsborrel 12 jan 2020 Dudok, Hilversum

[St Niklaas]

Hi Just,

Bedankt voor de update.
Zonder eet gelegenheid moet ik voor mijn dieet eerder afbreken om op etenstijd 
thuis te zijn. Met eten neem ik gewoon de tijd om te horen.

Nick

Ps Prettige Jaarwisseling
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk] OSM user diary etiquette

[Alex Kemp]

This is my first post within these mailman lists. Just in case I make 
some mistake that leads to this message not getting placed in the lists 
correctly, the post that I am trying to respond to is at:–

https://lists.openstreetmap.org/pipermail/talk/2019-June/082747.html

1. https://www.stopforumspam.com/forum/viewtopic.php?pid=50236#p50236 :
• (email) Re: [Ticket#201906221073] Alex: Enough with the Insults 
and Comdemnation (sic)
• 24/06/2019, 23:00: “we have removed your latest diary entry because it 
was considered too offensive”


The discussion in the post linked at top is very one-sided. None of the 
“obnoxious behaviour” can be viewed, since the posts mentioned have been 
removed. Well, joy! Although 12 posts total were deleted by the DWG, 
11 were saved by myself at the time and many of them can be viewed 
elsewhere so that unbiased persons can make up their own mind as to just 
how vile these posts were (not). So, in reverse order:–


(You will be disappointed if you are hoping to read lots of insults 
and/or swearing)


2. https://www.stopforumspam.com/forum/viewtopic.php?pid=50239#p50239 :
• A Stranger at your Table 2019-06-24
• (the word-for-word post mentioned in [1] above that sparked removal of 
all Spam-info posts in OSM Diaries)


3. https://github.com/openstreetmap/operations/issues/308 :
• Github email 2019-06-22: “A maintainer of the @openstreetmap 
organization has blocked you”


4. https://www.openstreetmap.org/user/alexkemp/diary/390252 :
• Post about AST Auto Centre + spam in OSM 2019-06-05, re-posted 
2019-08-06 (spam-related material removed for clarity): “PoI Musings”


5. https://www.stopforumspam.com/forum/viewtopic.php?pid=50184#p50184 :
• Post about spam in OSM 2019-05-18: “OSM is now within an iteration of 
spam-bot software (such as XRumer)”


6. https://www.openstreetmap.org/user/alexkemp/diary/390418 :
• Post about spam in OSM 2019-05-12, re-posted 2019-07-12: “How to Stop 
the Spam-Storm”


7. https://www.stopforumspam.com/forum/viewtopic.php?pid=50245#p50245 :
8. https://www.openstreetmap.org/user/alexkemp/diary/390250 :
• Post about spam in OSM 2019-05-06, re-posted 2019-07-12: “Recent Spam 
Attacks”
• (a set of statistics, originated to discover whether the then-recent 
spam attacks were human or bot-attacks)


9. https://www.openstreetmap.org/user/alexkemp/diary/158832 :
• Post about spam in OSM 2019-05-03: “Behold Cassandra”
• (this is the single post about spam in OSM that was NOT removed. Yet.)

10. https://www.stopforumspam.com/forum/viewtopic.php?pid=50404#p50404 :
• Email to TomH + Firefishy 2019-09-16: opportunity to use/test a 
k-anonymity SFS API (zero response)


In Summary:–

OSM == OpenStreetMap
DWG == Data Working Group

https://www.openstreetmap.org/diary
https://www.openstreetmap.org/user/alexkemp/diary

https://en.wikipedia.org/wiki/Narcissism
https://en.wikipedia.org/wiki/Cabal
https://en.wikipedia.org/wiki/Rat_king
https://en.wikipedia.org/wiki/Going_postal

A bunch of OSM folks, joined at the tail by the common mental 
disturbance known as Narcissism, got butt-hurt by (in part) the fact of 
my pointing out that they were malignant narcissists, and went postal on 
me. Unfortunately for myself, they
Ⅰ. had controls of levers that allowed them to remove Diary posts that, 
in some cases, had taken me more than 11 hours to research & write, and
Ⅱ. were malignant narcissists, which meant that they would do everything 
in their power to harm me.


If you stand to one side and kind of squint at all of this, and after 
reading all the available posts (above), and especially after reading 
the extract from the email sent to me by one of the executives of the 
DWG (bottom), you now need to re-join your bottom jaw to your top-jaw. 
And yes, this really is Real Life. And it is about to get worse, since 
it appears that some of these folks may be engaging in financial 
mismanagement (at best) and/or corruption (at worst)…


A. https://www.openstreetmap.org/user/Nakaner/diary/42916 :
• Post about 2017 OSMF Board Elections 2017-12-08: “analysis of the 
candidates”
• Heather Leson: “rarely active mapper … member of the HOT US Inc. … 
would like to introduce a strong code of conduct with an enforcement … 
emphasized her fundraising skills on the HOT board but did not collect 
any money” … et al
• Emails from Nicolas Chavent (co-founder of HOT) + Severin Menard 
(long-time member of HOT) reveal effects of a code of conduct complaint 
within HOT, plus it running out of money whilst Leson was in charge


B. https://www.openstreetmap.org/user/SeverinGeo/diary/42854 :
• Post in OSM Diary 2017-12-01: “Leaving the HOT US Corporation”
• Severin Menard: “secrecy and lies were core within the board toward 
the membership … End of September 2015, HOT US Inc should still have 
approximately USD $152,000 for activities still to be done or to be 
returned for one large multiple years project, while the bank account 
was around only USD $10K.”


C. 

Re: [OSM-talk-fr] Défusion de commune

[osm . sanspourriel]

Excuse valable. Tu fais les changements idoines dans 2 h ?
Bonne année deux mille vins... à ne pas prendre à la lettre mais à consommer 
avec modération


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

Re: [Talk-us] Wilderness areas separate from forest?

[Eric H. Christensen via Talk-us]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Sorry for the late entry to the discussion but I did have a little information 
to add here.

Wilderness, at least at the federal level, enjoys a different protection from 
that of a national forest.  There is to be no development or tree harvesting in 
such areas and even wildfire management may be different.  I wouldn't 
necessarily start combining the two together as they are managed differently 
and have different purposes and landuse protections.

Eric "Sparks"
-BEGIN PGP SIGNATURE-
Version: ProtonMail

wsFcBAEBCAAGBQJeC7ILAAoJEIB2q94CS7PRxsUP/3U96edPZ2FWSN6TnqjU
4THwLHaUHz2qOQTNjm0Ctef7BZbDgck7omAELU2OJUpYELoU71vvqu9PRvI0
YMupqUoHf41jU7RZ0VIZglq9hCo5/SZDJ7MMghNQ6ANewF00bUsFToVWltJp
hGT/07jw5Tz6gdZ/b5B9J9VLDqz4w5CXOCjMmhhY3LJ9kyn6E8DkBQa7seSV
lIHc8WuEIs127wpMuIQAfykg9BEEBy/3suIpUSzF6YR5Nb6uTn3KQifGFoP0
XwMUR7cKcMrdz/j8PW24rpazrbA3UmelcbA7pasOPd3Z8icHRCxhBilWIQt2
bIIPU9Q8809pxwTKpY8hHizl6lWTjnvLcdG4JG8L7G9PidnC3gl64HMtN4YF
5e8A2qUrYycm27meWMlhGr/R3wDUtkJd343uZn7OCAK2qUR5Ms5wA0MYCT7j
40l5e52JQ6TbcrVMzmzfuioE+i06BZ7sCsTOySl3PtC/YP1hjQc+lHyi2MpQ
EzUKJbUnjGH2in2mimJUxq9rq3xCEGQMTmXws7fnF7AlWuOShg+kDaWvwj9G
Fi5f+TrBuKGgdPFAIgDcpVnKWgtWkGxIvV0h6l1mCpFCRi+mT8COHp8SBOAq
DB7PpqspjCrAkKafzsIvHf0wfTWaQt+4XJvFjrhVRGFWxFQUPJJpj6Bq1g05
BbSJ
=AFMX
-END PGP SIGNATURE-


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

[OSM-talk-fr] Défusion de commune

[Donat ROBAUX]

Hello,

J'ai bien fait de regarder le 20h de TF1. Il est question de la défusion de
commune de Saline (14). Donc chaque commune repart chez soi: Troarn et
Sannerville au 1er janvier.

Le 28 décembre, le tribunal administratif de Caen a annulé l’arrêté
préfectoral portant sur la création de la commune nouvelle de Saline, à
compter du 31 décembre 2019 (pour que les décisions prises depuis la fusion
ne soient pas caduques). À cette date, Sannerville et Troarn redeviendront
deux communes distinctes.

Donat



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk] no-go-areas

[stevea]

I've certainly tagged plenty of natural=cliff (and I'm not done yet), there's 
lots of them around me.  So perhaps hazard=chasm could deprecate as one value 
of the proposed key hazard, deferring to natural=cliff.

Still, there are plenty of objective, not-going-away-soon, 
not-politically-sensitive hazards on Earth.  We should map and render them, but 
to do so, we might resurrect a more-modern version of the hazard tag proposal.  
Or anything else that would do the job.  These do seem like good, smart things 
to map.

Good dialog, thank you everybody.

SteveA

> On Dec 31, 2019, at 10:59 AM, Mateusz Konieczny  
> wrote:
> 
> 31 Dec 2019, 19:35 by stevea...@softworkers.com:
> Really? Actual, real-life hazards like [chasm
> natural=cliff?


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

Re: [OSM-talk] no-go-areas

[Mateusz Konieczny]

31 Dec 2019, 19:35 by stevea...@softworkers.com:

> Really?  Actual, real-life hazards like [chasm
>
natural=cliff?___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] Landuse between fences?

[Martin Wynne]

On 31/12/2019 18:10, Dave F via Talk-GB wrote:

I would add the appropriate surface=* tag to the way.


Thanks Dave.

But a way is a *line*.

I want to tag the *area*. I've got 3 ways - 2 fences and a track. 
Tagging ways is easy. Finding a meaningful tag for areas seems to be 
much more difficult.


If the landuse is the same on both sides, a field of cabbages on the 
left and a field of potatoes on the right, I can just let "farmland" 
flow across the track area. But if it is a wood on the right, where is 
the boundary between the wood and the cabbages? The track? Stitching 
things to highways is frowned on. Or one of the fences? Which one?


cheers,

Martin.


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

Re: [OSM-talk] no-go-areas

[stevea]

Really?  Actual, real-life hazards like [chasm, radiation, rock_slide, 
minefield...] are not worthy of that tag on a node and some Carto-code to toss 
up a triangle-! icon on our map?  Where's the harm?  (Literally).

Perhaps we implement these without including (or specifically EXcluding) the 
more "sensitive" ones which are considered "subjective."  We can't be "too 
subjective" if we aren't subjective at all.  But, explicitly objective hazards 
do seem worthy to map.

Many (most?) like radiation, live minefields, military bombing areas, sharp 
bluffs / cliffs are not transient at all and would likely remain as long-term 
hazards.

I think we should revisit this rather than dismiss it matter-of-factly as "oh, 
that hazard thing that pops its head up every year or so."

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

Re: [OSM-talk] no-go-areas

[Dave F via talk]

This question rears its head every year or so & the conclusions are 
always the same:


Far too subjective, Far too transient. Best left to be shown as an 
overlay by local authorities.

My police force produce both crime & road traffic collision maps.

DaveF

On 31/12/2019 15:14, Martin Trautmann wrote:

hi all,

did you read about the Suisse tourist couple which was shot because they
got lost in a Brasilian favela?

NZZ (Neue Zürcher Zeitung) from Tuesday 31.12.2019. ("Schweizer Ehepaar
bei Irrfahrt duch Favela in Brasilien
angeschossen")

Other examples are e.g. Mafia areas within Kosovo - or name your own
home town no-go area.

Is there any option to mark certain areas in order to bypass routing
whenever possible?


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


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

Re: [Talk-GB] Landuse between fences?

[Dave F via Talk-GB]

I would add the appropriate surface=* tag to the way.

DaveF

On 31/12/2019 16:38, Martin Wynne wrote:

Here is a track/public bridleway:

 http://85a.uk/coffin_way_960x520.jpg

which I can easily map as such.

But that is just a *centre-line*. If I add the fences, what is the 
correct landuse tag for the area between them? I can't find any tag 
which seems to apply.


Everywhere I look on OSM such areas are left blank. But it can 
represent a significant area, sometimes 20 feet wide -- much larger 
than other areas on OSM which are mapped in great detail. If it was a 
canal for example, its banks could be separately mapped and the area 
between them mapped as water. Tracks and fences/hedgerows don't seem 
to have anything comparable.


Thanks.

Martin.

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



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

Re: [OSM-talk] no-go-areas

[Mark Wagner]

On Tue, 31 Dec 2019 16:14:30 +0100
Martin Trautmann  wrote:

> hi all,
> 
> did you read about the Suisse tourist couple which was shot because
> they got lost in a Brasilian favela?
> 
> NZZ (Neue Zürcher Zeitung) from Tuesday 31.12.2019. ("Schweizer
> Ehepaar bei Irrfahrt duch Favela in Brasilien
> angeschossen")
> 
> Other examples are e.g. Mafia areas within Kosovo - or name your own
> home town no-go area.
> 
> Is there any option to mark certain areas in order to bypass routing
> whenever possible?
> 

The problem is that most of these "no-go" areas are subjective, both in
boundary and in level of danger.  If you ask a half-dozen people, you
might get a half-dozen responses ranging from "I go there all the time"
to "The police don't patrol in less than platoon strength".

-- 
Mark

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

Re: [OSM-talk-fr] absence de BAN dans BANO

[deuzeffe]

Le 31/12/2019 à 16:09, Vincent de Château-Thierry a écrit :


il n'y a donc plus de raison pour ne pas faire ce mix dans BANOv2
:)


\o/


oui yapluka, un sujet pour le début de l'année :)


C'était bien pour préparer le terrain, dans cette optique, que toi et 
tes acolytes (dont les noms m'échappent pour l'heure - ybon ?) avez 
relancé un osm-vs-fantoir digne de la 3e décennie du 3e millénaire, non 
? Ou alors osm-vs-fantoir=BANOv2 ?


--
deuzeffe, qui s'y perd.

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

Re: [Talk-GB] Landuse between fences?

[SK53]

There is a surprisingly heavily used landuse=highway

for highway corridors, by analogy with landuse=railway. I would think it is
mainly used for motorway corridors which can be considerably wider than the
carriageways, and even then other landuse/natural tags may be used for
parts of the area. See around Colwyn Bay .

However, in this case I think the primary landuse is agriculture, which
works more easily if areas larger than a field are mapped at a time. I see
little reason to add a landuse here: most use cases requiring tessellated
landuse can either process highway by type perfectly adequately, or fill
holes by use of buffering operations. I used some simple defaults for
highway width back in 2011 which produced results very similar to data
which had been explicitly mapped as areas.

Jerry

On Tue, 31 Dec 2019 at 16:39, Martin Wynne  wrote:

> Here is a track/public bridleway:
>
>   http://85a.uk/coffin_way_960x520.jpg
>
> which I can easily map as such.
>
> But that is just a *centre-line*. If I add the fences, what is the
> correct landuse tag for the area between them? I can't find any tag
> which seems to apply.
>
> Everywhere I look on OSM such areas are left blank. But it can represent
> a significant area, sometimes 20 feet wide -- much larger than other
> areas on OSM which are mapped in great detail. If it was a canal for
> example, its banks could be separately mapped and the area between them
> mapped as water. Tracks and fences/hedgerows don't seem to have anything
> comparable.
>
> Thanks.
>
> Martin.
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-GB] Landuse between fences?

[Martin Wynne]

Here is a track/public bridleway:

 http://85a.uk/coffin_way_960x520.jpg

which I can easily map as such.

But that is just a *centre-line*. If I add the fences, what is the 
correct landuse tag for the area between them? I can't find any tag 
which seems to apply.


Everywhere I look on OSM such areas are left blank. But it can represent 
a significant area, sometimes 20 feet wide -- much larger than other 
areas on OSM which are mapped in great detail. If it was a canal for 
example, its banks could be separately mapped and the area between them 
mapped as water. Tracks and fences/hedgerows don't seem to have anything 
comparable.


Thanks.

Martin.

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

Re: [OSM-talk-fr] absence de BAN dans BANO

[Philippe Verdy]

Les données LO/OL sont programmées pour s'éteindre ? N'est-ce pas l'OdBL
qui rassemble tout le monde à terme?
Et l'ODbL de toute façon impose l'attribution, comme la licence LO/OL, je
ne vois pas ce que ça change (pour que ce soit clair et ne pas avoir à
l'indiquer sur des tonnes d'objets)

Les fournisseurs libres les plus fréquents sont mentionnés sur la page de
copyright d'OSM, de sorte qu'il n'est plus nécessaire de mentionner ces
sources dans les données OSM elles-mêmes.

Et ces sources restent encore dans les tags sources des changesets, surtout
les sources d'imagerie (où on peut aussi les dater, surtout pour les
besoins de maintenance ultérieure, histoire de savoir quel jeu historique
de données a été utilisé et si une mise à jour ultérieure de la source ne
devrait pas les modifier, ça sert à avoir une idée de la fraicheur des
données pour les tags individuels; sinon chaque objet OSM a une date de
version, mais cela ne trace pas la date de la source, ce peut être
n'importe quelle correction secondaire, comme un recalage, une scission de
noeud, faire un peu de place pour poser plus précisément d'autres objets à
côté, pas mal de modifs étant faites pour être plus précises
géométriquement que la source d'origine qui ne visait pas les objets
voisins; des tas de modifs étant nécessaire pour le travail de fusion et
préparation des autres données ajoutées; d'autres modifs sont des
traductions ajoutées librement ne venant pas des sources monolingues
d'origine, donc la date des objets OSM n'est pas toujours le bon indicateur
de la fraicheur de la source utilisée).

Le mar. 31 déc. 2019 à 16:50, marc marc  a
écrit :

> Le 31.12.19 à 15:51, Christian Quest a écrit :
> > la BAN sera dispo "avant la fin de l'année" sous Licence Ouverte, donc
> > compatible avec l'ODbL d'OSM et de BANO.
>
> je n'ai pourtant pas encore commencé le réveillon.
> mais depuis quand l'obligation d'attribution de la LO est compatible
> avec l'absence d'attribution des sources contribuant à osm ?
> si j'affiche la carte d'un changeset provenant d'une source LO,
> il y a pas d'attribution "donnée venant de cette source LO"
> c'est pour cela qu'il me semblait qu'on devait se farcir
> des demandes d'exeption pour que la source accepte de renoncer
> à l'attribution et se contente d'être mentionné dans les sources
> contribuant à osm
>
> Je suis en tout cas ravi si la BANOv2 ou v3 (surtout ses outils
> à la contribution osm) incluera la BAN en dernier resort.
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] no-go-areas

[stevea]

As a long-time OSMer, I offer perspective on two "dangerous areas" near me, one 
past, one present.

On my university campus (University of California) there WAS an area in a 
meadow which was grazed by cattle (both from the original landuse from a 
century ago and presently, as these meadows are grazed by cattle even today, at 
a university of tens of thousands of students).  A decade and longer ago, there 
was a swale (low-lying area) which I believe was human-converted into a sort of 
reservoir for watering cattle, but it had steep sides, was quite deep and could 
be impossible for humans or cattle to escape if they fell into it, especially 
when empty / dry.  Not by me, but this was marked on OSM as a "no go area," 
which I always found curious, as that wasn't an explicitly defined tag.  I'm 
nearly certain that today, this dangerous area has been "remedied" (filled in 
with dirt) and no longer exists as a hazard on campus.  In OSM, there is no 
longer anything (node, way) in the area to tag as such; it has effectively 
disappeared from both the real world and our map.

Also near me is a "beach" (it sort of is, sort of isn't) which is a dangerous 
place to ocean-swim, it is known locally as the "Toilet Bowl" as it has nasty 
churning surf and undertow currents which I believe have drowned at least one 
person.  When I heard local news that such a drowning occurred yet again, I 
endeavored to tag a node there with name=Toilet Bowl (dangerous area, no 
swimming) + swimming=no + hazard=yes.  (Yes, I know that violates "name is name 
only").  Also, there isn't a "physical" tag (like natural=beach, as that is 
unusual, though not wholly wrong, on a node).  Yet I couldn't help but feel 
that hazard=yes, a "draft / underway proposal" (since 2007?! really?) is 
insufficient:  the value "yes" isn't documented in the proposal, and others 
listed there, like chasm, radiation, rock_slide, minefield, playing_children... 
didn't fit a dangerous swimming area.  Plus, the hazard tag doesn't render (a 
triangle with exclamation point might be a good starting icon).

I believe OSM needs better, explicit tagging to identify dangerous, hazardous 
areas, and Carto should render these.  There are many different kinds of these, 
from those I just noted, to "high-crime area" and what others might consider 
sensitive or political.  (We shouldn't be afraid to say that an explicit hazard 
exists if one does).  A proposal that seems to have gotten stuck for 12 years 
seems it's a good starting point, can it be resurrected?  OSM mapping these 
would be another welcome feature in our map, as I know of no other 
general-purpose map (that IS how many use OSM) which identifies these sorts of 
"everyday" hazards.  Think about it:  a hazardous situation might find YOU one 
day, and you might be very glad you saw this on a map beforehand so you could 
avoid it.

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

Re: [OSM-talk-fr] SPAM, Re: Problème avec ID - besoin d'aide

[Philippe Verdy]

Voilà comment une spécif est devenue illisible et c'est à moi qu'on vient
dire que supprimer les espaces non nécessaires serait illisible?
Il y a trop de règles ici, le "fallback" (||) ne sert à rien et complique
inutilement, la syntaxe indiquée n'étant même pas correctement spécifiée en
terme d'associativité.
Et je ne vois pas du tout pourquoi deux règles "Mo 08:00-12:00;Mo
14:00-18:00" sont fausses (même si ici c'est évidemment équivalent à une
seule règle combinée/factorisée "Mo 08:00-12:00,14:00-18:00 en utilisant la
virgule simplement comme séparateur secondaire entre deux horaires des
mêmes dates, ou entre deux dates au même horaire).
la présence ou pas du qualificateur final "off" ne devrait strictement rien
changer à l'associativité.

Et puis cette "doc" ne suit même pas tous les usages de l'outil de test que
tu utilises, il y a d'autres outils mais franchement cette page de doc est
très orientée selon une définition à priori non testée et qui ne fonctionne
pas telle quelle et n'a en fait été suivi exactement par /personne/.

"opening_hours" est conçu n'importe comment, pas pour être lisible, et
plein d'ambiguités comme sa doc. chacun y a mis sa sauce sans vérifier
comment les autres utilisaient ou analysaient le reste.

C'est tellement plus simple (même pour un lecteur humain) de concevoir un
traitement cumulatif et un traitement ordonné des règles. Ensuite on peut
discuter de la façon de scinder les horaires sur plusieurs tags numérotés
(c'est simpel de voir où on peut couper: partout où un point-virgule est
admis, mais il faut une règle d'ordre donc une convention de nommage pour
le numéro dans la clé). Pas besoin de base externe avec une URL qui ne sera
jamais traitée (et qui ne sert à rien: autant utiliser website=* pour le
site officiel mentionnant sur sa page d'info les horaires, et qu'on
visitera alors dans un navigateur); ce ne sera jamais plusieurs dizaines de
kilooctets comem pour toute une page web avec son HTML, ses styles, ses
images, ses scripts, ses publicités et traqueurs web et autres formulaires.
et toute la déco et l'animation voire le son et la vidéo qui vont avec ou
des éléments "dangereux/malveillants", sinon intrusifs (boutons sociaux,
Google Sense, vendeurs en ligne, etc) et qui vous suivent ensuite partout
où vous allez sur le web et permettent à des tiers de faire du
rapprochemetn de donénes massif.

Qui utilise le "fallback" (||), qui ne sert à rien? On peut faire bien plus
simple sans lui. Deux séparateurs de règles (un majeur ";" et un mineur ","
suffisent à tout et ça ne cause aucune difficulté d'interprétation aussi
bien pour un robot et c'est le maximum compréhensible par un humain).



Le mar. 31 déc. 2019 à 14:49, Jérôme Seigneuret 
a écrit :

> C'est un truc de fou quand même d'être aussi têtu!
> Tu me parles du comportement du mot clé *off. *Ca n'a rien à avoir avec
> ce que je mentionne!
>
> Pour rappel ta proposition c'est ça à la base
> *Mo-Fr 11:45-14:00,17:00-20:00;*
> *We 11:30-11:45; < ici tu n'ajoutes pas un horaire mais tu le respécifies
> pour le jour en question*
> *Mo 11:45-12:00 off; < là ok*
> *We 13:00-14:00,18:00-20:00 off;< le off ne sert à rien mercredi a été
> redéfini uniquement de 11h30 à 11h45*
> *Tu 20:00-21:00;  < ici tu respécifie la fourchette horaire d'ouverture
> pour le jour en question entre 20h et 21h*
>
> *Donc c'est bien incohérent que tu veuilles le comprendre ou pas.*
> Tu et We ne sont pas en *off *et annule le comportement du jour en
> question sur le sélecteur précédent Mo-Fr en surchargeant le comportement
> vu que tu lui affecte une nouvelle plage horaire!
>
> le rôle additionnelle est le séparateur *, *pas *; les éléments séparé
> par des ; sont des *roles* qui écrase des valeurs précédemment défini de
> gauche à droite. Le mot clé off désactive des plages défini du comportement
> initial il sert à annuler des parties de critères mentionnés comme ouvert
> et là pas de problème tu as bon!*
>
> Rule separators
>  
> 
>  | 
> 
>  | 
> 
>  *;* 
> 
>  *,* 
> 
>  Limitations
> and Explanation
> 
> 
>
> 
> 
>  *||* 
> 
> Explanation
> 
>
> *A additional rule is treated exactly the same as a normal rule
> 

Re: [OSM-talk] no-go-areas

[James]

Wouldn't that just be a crime map or a bias towards areas vs others.

Sounds like an osm use case more than a needed tag

On Tue., Dec. 31, 2019, 10:18 a.m. Martin Trautmann,  wrote:

> hi all,
>
> did you read about the Suisse tourist couple which was shot because they
> got lost in a Brasilian favela?
>
> NZZ (Neue Zürcher Zeitung) from Tuesday 31.12.2019. ("Schweizer Ehepaar
> bei Irrfahrt duch Favela in Brasilien
> angeschossen")
>
> Other examples are e.g. Mafia areas within Kosovo - or name your own
> home town no-go area.
>
> Is there any option to mark certain areas in order to bypass routing
> whenever possible?
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] absence de BAN dans BANO

[marc marc]

Le 31.12.19 à 15:51, Christian Quest a écrit :
> la BAN sera dispo "avant la fin de l'année" sous Licence Ouverte, donc
> compatible avec l'ODbL d'OSM et de BANO.

je n'ai pourtant pas encore commencé le réveillon.
mais depuis quand l'obligation d'attribution de la LO est compatible
avec l'absence d'attribution des sources contribuant à osm ?
si j'affiche la carte d'un changeset provenant d'une source LO,
il y a pas d'attribution "donnée venant de cette source LO"
c'est pour cela qu'il me semblait qu'on devait se farcir
des demandes d'exeption pour que la source accepte de renoncer
à l'attribution et se contente d'être mentionné dans les sources
contribuant à osm

Je suis en tout cas ravi si la BANOv2 ou v3 (surtout ses outils
à la contribution osm) incluera la BAN en dernier resort.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-ko] weeklyOSM #492 2019-12-17-2019-12-23

[weeklyteam]

매주 일어나는 OSM 소식을 종합한, 492번째 주간OSM이 발행되었습니다.

http://www.weeklyosm.eu/ko/archives/12676/

읽어 주셔서 감사합니다!
셨나요? 그냥 https://osmbc.openstreetmap.de/login 에 들어가서 오픈스트리트맵 계정으로 로그인하기만 하면 됩니다. 
기사 작성법 등의 정보는 여기를 참조하세요.
주간OSM이란? 
누가?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
어디서?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ko mailing list
Talk-ko@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ko

Re: [Talk-it] Negozio abbigliamento sportivo brand unico.

[liste_girarsi]

Il 31 Dicembre 2019 15:37:18 CET, scratera  ha scritto:
>..vedo zaini in vetrina 
>https://www.montura.it/file_public/alpstation_store/102/gallery/_6.jpg
>..e in futuro si allrgherà l'offerta da parte del buon Roberto ideatore
>del
>brand...
>
>
>
>--
>Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
>___
>Talk-it mailing list
>Talk-it@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-it

boh, può essere vendano anche quelli, non sono mai entrato da quando l'hanno 
aperto.

--simone girardelli--
##
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.

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

Re: [OSM-talk-nl] OSGeo.nl/OSM-NL/QGIS-NL Nieuwjaarsborrel 12 jan 2020 Dudok, Hilversum

[Just van den Broecke]

Hoi Nick,

Alles is als voorheen, dus er is gelegenheid tot blijven eten.
Staat genoemd in de Meetup:
https://www.meetup.com/OSGeoNL/events/267249156/. Is wel op eigen kosten.

Tot dan!

Groet,

Just

On 31-12-19 12:35, St Niklaas wrote:

Hi Just,

Bedankt voor de uitnodiging.
Bij vorige meetingen zat er nog de gelegenheid tot eten aan vast, is dat 
gewijzigd ?

Want het wordt niet genoemd, klopt mijn gevoel en mag ik dat zelf regelen ?

Nick
OSM

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



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

[talk-cz] WeeklyOSM CZ 491

[Tom Ka]

Ahoj, je dostupné vydání 491 týdeníku WeeklyOSM:

https://weeklyosm.eu/cz/archives/12659

* Stahování GPX do JOSM.
* Aktualizace Strava pro SK.
* Jak přidávat detaily do OSM.
* Pozastavené podklady Maxar.
* Smutná budoucnost OSM.
* Zákaz varování před kamerami.
* Provázání Wikidata a OSM.
* Analýza voleb do rady Nadace OSM.
* OWG musí být zničena.
* FOSGIS 2020 ve Freiburgu.
* Testování Tasking Manageru 4.
* Haiku generátor z OSM.
* Jak na pítka v OSM.
* Mapy veřejné dopravy.
* Miliarda snímků v Mapillary.

Pěkné počtení ...

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

[OSM-talk] no-go-areas

[Martin Trautmann]

hi all,

did you read about the Suisse tourist couple which was shot because they
got lost in a Brasilian favela?

NZZ (Neue Zürcher Zeitung) from Tuesday 31.12.2019. ("Schweizer Ehepaar
bei Irrfahrt duch Favela in Brasilien
angeschossen")

Other examples are e.g. Mafia areas within Kosovo - or name your own
home town no-go area.

Is there any option to mark certain areas in order to bypass routing
whenever possible?



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] absence de BAN dans BANO

[Vincent de Château-Thierry]

> De: "deuzeffe" 
> 
> Le 31/12/2019 à 15:51, Christian Quest a écrit :
> 
> > Cette convention est caduque, la BAN va enfin être totalement
> > ouverte...

Je réalise que la fin de la convention n'a pas eu de publicité ici ni sur la ML 
"Association", mais on en a parlé ici :
https://www.loomio.org/d/s3mrKhQT/ban-r-siliation-de-la-convention-de-2015-projet-d-accord-des-fondateurs

> > il n'y a donc plus de raison pour ne pas faire ce mix dans BANOv2
> > :)
> 
> \o/

oui yapluka, un sujet pour le début de l'année :)

vincent

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

Re: [OSM-talk-fr] absence de BAN dans BANO

[Philippe Verdy]

Le mar. 31 déc. 2019 à 15:52, Christian Quest  a
écrit :

> Comme l'a écrit vdct, la BAN sera dispo "avant la fin de l'année" sous
> Licence Ouverte, donc compatible avec l'ODbL d'OSM et de BANO.
>
> Donc on a laissé le champ libre pour que la BAN avance, et c'était aussi
> une façon de jouer le jeu vue la convention que nous avions signé.
>
> Cette convention est caduque, la BAN va enfin être totalement ouverte...
> il n'y a donc plus de raison pour ne pas faire ce mix dans BANOv2 :)
>

En dehors des collectivités, l'arrivée de l'ARCEP pourrait inclure de
nouvelles données d'autres fournisseurs (pas que la Poste mais tous les
opérateurs de courrier et de télécommunications, et même des opérateurs de
réseaux, gaz/électricité, traitement des eaux, réseau ferré). Il serait
intéressant d'avoir les données de la Sécurité Civile (dont les pompiers)
et même pourquoi pas les armées (anciennes données de l'état-major), je ne
sais pas si c'est encore maintenu au delà des anciennes cartes, mais il
doit y avoir encore pas mal de terrains de l'armée accessibles au public),
les chambres d'agriculture, sociétés de chasse, agences de bassin, parcs
naturels, données forestières (pas encore incluse dans les données ONF),
Météo France, administration du littoral, etc... Pas toutes des adresses
mais des tas de lieux-dits et qui peuvent aussi aider les communes à nommer
leurs voies sur des bases bien fondées par un usage et la connaissance du
terrain et l'histoire.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] absence de BAN dans BANO

[deuzeffe]

Le 31/12/2019 à 15:51, Christian Quest a écrit :

Cette convention est caduque, la BAN va enfin être totalement ouverte... 
il n'y a donc plus de raison pour ne pas faire ce mix dans BANOv2 :)


\o/

(alors Marc-marc, heureux ? ^^)
--
deuzeffe - pas que lui, d'ailleurs...

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

Re: [OSM-talk-fr] absence de BAN dans BANO

[Christian Quest]

Comme l'a écrit vdct, la BAN sera dispo "avant la fin de l'année" sous
Licence Ouverte, donc compatible avec l'ODbL d'OSM et de BANO.

Pourquoi n'avoir jamais intégré la BAN ODbL dans BANO ?

C'est un choix disons "politique"... la BAN a eu tellement de mal à naître
et à ne pas être enterrée dans la foulée, que côté BANO on s'est retenu de
faire la base la plus à jour et complète qui soit.

En effet, BANO a comme avantages:
- un cycle de mise à jour potentiellement plus court (une correction dans
OSM se retrouve le lendemain dans BANO)
- des sources plus diverses d'adresses (cadastre souvent mieux exploité
qu'il ne l'était dans la BAN "v0", des sources opendata venant des
collectivités)
- bien plus d'adresses sans numéro, typique pour les lieux-dits

Donc on a laissé le champ libre pour que la BAN avance, et c'était aussi
une façon de jouer le jeu vue la convention que nous avions signé.

Cette convention est caduque, la BAN va enfin être totalement ouverte... il
n'y a donc plus de raison pour ne pas faire ce mix dans BANOv2 :)


Le mar. 31 déc. 2019 à 13:01, marc marc  a
écrit :

> Bonjour,
>
> Quelle est la raison pour ne pas intégrer la BAN Odbl dans BANO ?
> Dans certaines commune, BANO est pauvre, par ex Ceyzérieu 01073
> Bano ne contient même pas l'adresse de la mairie
> et de nombreuses voies "sans adresse" dans BANO
> ont des adresses dans la BAN.
> ex Rue de Bourbouillon
>
> il parait qu'elle ne serra plus publiée à partir de demain :(
> p'tre que Christian en ferra un archivage :)
>
> Cordialement,
> Marc
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

[OSM-talk-ie] Summits imported from mountainviews.ie

[Donal Diamond]

Just re-subscribed.

The MV import was done in Jan 2009 (eek!) after myself and Dermot met with
Simon.

Before import there was a total of 40 Irish summits in OSM. Back then, the
whole Irish map was a whole lot of nothing - we didn't even have county
boundaries - just shows how much progress we made the last 10 years!

At the time wiki guidance was ele was in wgs84,

' For OpenStreetMap, please use the elevation above sea level defined by
the World Geodetic System
, revision WGS 84.'

https://wiki.openstreetmap.org/w/index.php?title=Key:ele=209140

To answer some questions:
tm75 is basically Irish Grid https://epsg.io/29903
The tm75 elevations should be really close to egm96

iemv tags worth keeping? I'd probably just keep  iemv:mtnindex to help with
future updates from MV data.  There may still be an export page at
https://mountainviews.ie/mv/place_dump.php

The MV data has improved massively since 2009 as they have access to highly
accurate DGPS survey equipment - so worth a hackaton to refresh


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

Re: [OSM-talk-fr] absence de BAN dans BANO

[Philippe Verdy]

Ou alors "Guichet Ouvert" désigne aussi d'autres sources qui acceptent de
fournir leurs données, comme Waze, voire Google (données collectées par ses
streetcars ou les photos partagées par les utrilisateurs sur les sites
Google), ou encore Mapillary ?

Le mar. 31 déc. 2019 à 15:44, Philippe Verdy  a écrit :

> Intéressant, c'est surtout la base DGFip 2018 (BAN) qui est remplacé par
> la base DGFiP 2018 sous OdBl avec plus de sources (L'ARCEP en plus et
> bientôt sans doute à la place de La Poste.
> C'est le début de la fin de la BAN vers la base commune ODbL (totalement
> compatible BANO/OSM donc); je me demande pourtant l'intérêt du changement
> de l'ancvienne licence adhoc vers la LO/OL pour finalement n'y retrouver
> qu'une partie des données ODbL (le jeu qui devrait être le plus complet et
> le plus intéressant pour nous), puisque sous OL/LO on n'a pas la Poste (fin
> de vie de ce jeu de toute façon, remplacé par celui de l'ARCEP) ni les
> données IGN.
>
> Où est-on, nous OSM, dans le schéma
> https://adresse.data.gouv.fr/donnees-nationales: c'est nous le "Guichet
> Adresse" (inclus dans les trois jeux de données) ?
>
>
> Le mar. 31 déc. 2019 à 14:53, Vincent de Château-Thierry 
> a écrit :
>
>> Bonjour,
>>
>> > De: "marc marc" 
>> >
>> > Quelle est la raison pour ne pas intégrer la BAN Odbl dans BANO ?
>> > Dans certaines commune, BANO est pauvre, par ex Ceyzérieu 01073
>> > Bano ne contient même pas l'adresse de la mairie
>> > et de nombreuses voies "sans adresse" dans BANO
>> > ont des adresses dans la BAN.
>> > ex Rue de Bourbouillon
>> >
>> > il parait qu'elle ne serra plus publiée à partir de demain :(
>> > p'tre que Christian en ferra un archivage :)
>>
>> Pas de panique, la BAN change de licence ce soir à minuit, sans pour
>> autant devenir incompatible avec OSM ni BANO :
>>
>> https://adresse.data.gouv.fr/donnees-nationales
>>
>> Et bon réveillon à tou.te.s
>>
>> vincent
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] absence de BAN dans BANO

[Philippe Verdy]

Intéressant, c'est surtout la base DGFip 2018 (BAN) qui est remplacé par la
base DGFiP 2018 sous OdBl avec plus de sources (L'ARCEP en plus et bientôt
sans doute à la place de La Poste.
C'est le début de la fin de la BAN vers la base commune ODbL (totalement
compatible BANO/OSM donc); je me demande pourtant l'intérêt du changement
de l'ancvienne licence adhoc vers la LO/OL pour finalement n'y retrouver
qu'une partie des données ODbL (le jeu qui devrait être le plus complet et
le plus intéressant pour nous), puisque sous OL/LO on n'a pas la Poste (fin
de vie de ce jeu de toute façon, remplacé par celui de l'ARCEP) ni les
données IGN.

Où est-on, nous OSM, dans le schéma
https://adresse.data.gouv.fr/donnees-nationales: c'est nous le "Guichet
Adresse" (inclus dans les trois jeux de données) ?


Le mar. 31 déc. 2019 à 14:53, Vincent de Château-Thierry 
a écrit :

> Bonjour,
>
> > De: "marc marc" 
> >
> > Quelle est la raison pour ne pas intégrer la BAN Odbl dans BANO ?
> > Dans certaines commune, BANO est pauvre, par ex Ceyzérieu 01073
> > Bano ne contient même pas l'adresse de la mairie
> > et de nombreuses voies "sans adresse" dans BANO
> > ont des adresses dans la BAN.
> > ex Rue de Bourbouillon
> >
> > il parait qu'elle ne serra plus publiée à partir de demain :(
> > p'tre que Christian en ferra un archivage :)
>
> Pas de panique, la BAN change de licence ce soir à minuit, sans pour
> autant devenir incompatible avec OSM ni BANO :
>
> https://adresse.data.gouv.fr/donnees-nationales
>
> Et bon réveillon à tou.te.s
>
> vincent
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Negozio abbigliamento sportivo brand unico.

[scratera]

..vedo zaini in vetrina 
https://www.montura.it/file_public/alpstation_store/102/gallery/_6.jpg
..e in futuro si allrgherà l'offerta da parte del buon Roberto ideatore del
brand...



--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [Talk-it] Negozio abbigliamento sportivo brand unico.

[liste DOT girarsi AT posteo DOT eu]

Il 31/12/19 14:33, scratera ha scritto:
> ...vendono
> zaini...corde..moschetoni..imbracature...fettucce..ramponi...racchette da
> nevescarpe e scaponi anche da sci...tende..etc...
> 
> 

In quello di Borgo Valsugana vendono solo abbigliamento, e forse
scarpe/scarponi.


-- 
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|
Simone Girardelli

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

Re: [OSM-talk-fr] absence de BAN dans BANO

[Vincent de Château-Thierry]

Bonjour,

> De: "marc marc" 
> 
> Quelle est la raison pour ne pas intégrer la BAN Odbl dans BANO ?
> Dans certaines commune, BANO est pauvre, par ex Ceyzérieu 01073
> Bano ne contient même pas l'adresse de la mairie
> et de nombreuses voies "sans adresse" dans BANO
> ont des adresses dans la BAN.
> ex Rue de Bourbouillon
> 
> il parait qu'elle ne serra plus publiée à partir de demain :(
> p'tre que Christian en ferra un archivage :)

Pas de panique, la BAN change de licence ce soir à minuit, sans pour autant 
devenir incompatible avec OSM ni BANO :

https://adresse.data.gouv.fr/donnees-nationales

Et bon réveillon à tou.te.s 

vincent

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

Re: [OSM-talk-fr] SPAM, Re: Problème avec ID - besoin d'aide

[Jérôme Seigneuret]

C'est un truc de fou quand même d'être aussi têtu!
Tu me parles du comportement du mot clé *off. *Ca n'a rien à avoir avec ce
que je mentionne!

Pour rappel ta proposition c'est ça à la base
*Mo-Fr 11:45-14:00,17:00-20:00;*
*We 11:30-11:45; < ici tu n'ajoutes pas un horaire mais tu le respécifies
pour le jour en question*
*Mo 11:45-12:00 off; < là ok*
*We 13:00-14:00,18:00-20:00 off;< le off ne sert à rien mercredi a été
redéfini uniquement de 11h30 à 11h45*
*Tu 20:00-21:00;  < ici tu respécifie la fourchette horaire d'ouverture
pour le jour en question entre 20h et 21h*

*Donc c'est bien incohérent que tu veuilles le comprendre ou pas.*
Tu et We ne sont pas en *off *et annule le comportement du jour en question
sur le sélecteur précédent Mo-Fr en surchargeant le comportement vu que tu
lui affecte une nouvelle plage horaire!

le rôle additionnelle est le séparateur *, *pas *; les éléments séparé par
des ; sont des *roles* qui écrase des valeurs précédemment défini de gauche
à droite. Le mot clé off désactive des plages défini du comportement
initial il sert à annuler des parties de critères mentionnés comme ouvert
et là pas de problème tu as bon!*

Rule separators
 

 | 

 | 

 *;* 

 *,* 

Limitations
and Explanation





 *||* 

Explanation


*A additional rule is treated exactly the same as a normal rule
,
except that a additional rule does not overwrite the day for which it
applies (unlike the normal separator which starts always with a new, empty
day, deleting any pervious rules applying the given day). Note that a
additional rule does not use any data from previous or from following
rules. If time wraps over midnight are involved then you will probably also
need to use additional rules to not overwrite the part which wraps into the
next day. It can also be used to specify different comments

for
one day. Read more (including some examples) in this issue on github
.*

*Because of the peskiness that the 

is
the same token as the token to separate lists (e.g. 

{ , 

})
the , (comma) is only interpreted as 

if
it follows after one of those symbols:*

   - **
   

   - **
   



Il me semble que tu es meilleur en anglais que moi mais je n'ai pas inventé
ce que j'écris et || est bien dans la spécification en cours sinon c'est
que le wiki à besoin d'un petit rafraichissement comme le site
https://openingh.openstreetmap.de/evaluation_tool

La fallback empèche l'écrasement de valeur et est utilisé par défaut pour
présenter plusieurs situation avec c'est ça et ça avec des commentaires
pour préciser les deux situations. Informatique ça renvoi le bon résultat.

C'est loin d'être un critère de compatibilité vu que c'est dans les
spécifications officielle et que je comportement est opposé au mot clé
*off * c'est pas non plus remplacé vu que c'est encore dans le code source
avec des exemples ajouté en issues
https://openingh.ypid.de/netzwolf_mirror/time_domain/explanation.html
*Multiple rulesets can be concatenated using ||.   *

Maintenant on peut compléter avec l'auteur

et
le code source du projet les exemples pour voir la prise en compte ou non
de ce comportement.





Le mar. 31 déc. 2019 à 13:25, Philippe Verdy  a écrit :

> Bref:
> - "08:00-19:00;12:00-14:00 off" est équivalente à  "08:00- 12:00;14:00-
> 19:00"
> - "08:00-19:00;Sa-Su off" est équivalente à  "Mo-Th 

Re: [Talk-us] FW: US Bicycle Route 1 through Daytona Beach

[Sam Ley]

Hi Kerry,

That is a bit of an odd trail spur to be included in the greenway, since it
just dodges off of Beach St, and then right back on, but maybe passing by
the park gives some opportunity for restrooms that would ordinarily be
missed. I've added it, and connected it to the ECG relation so it should
start showing up on OSM driven maps soon.

-Sam


> Clifford,
>
>
>
> Paved.  The city wants the ECGW and USBR 1 to be co-designated, and the
> ECGW map (https://map.greenway.org
> ) shows
> this bike path as being on the ECGW.
>
> Kerry
>
>
>
> *From:* Clifford Snow 
> *Sent:* Monday, December 30, 2019 7:46 PM
> *To:* Kerry Irons 
> *Cc:* talk-us 
> *Subject:* Re: [Talk-us] FW: US Bicycle Route 1 through Daytona Beach
>
> Kerry - the new cycle path has been added. See
> https://www.openstreetmap.org/#map=19/29.19623/-81.01173
> 
>
> Do you know if it is paved or what kind of surface? Is it supposed to
> connect to the ECG, the East Coast Greenway route? From Strava it doesn't
> appear to?
>
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-it] Negozio abbigliamento sportivo brand unico.

[scratera]

...vendono
zaini...corde..moschetoni..imbracature...fettucce..ramponi...racchette da
nevescarpe e scaponi anche da sci...tende..etc...



--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [OSM-talk-fr] Plusieurs relations pour la même rue...

[Jacques Lavignotte]

Le 31/12/2019 à 09:28, Jacques Lavignotte a écrit :

Je vais aller voir sur place.


Vu sur place :


Chemin : Rue des Libellules (72456629) est une allée privée qui dessert 
la maison en retrait de la rue des Libellules « Chemin : 84864716 »


Elle ne porte pas de plaque de rue.

La boîte à lettres et le numéro de rue (3) sont sur le muret en bord de 
rue « Chemin : Rue des Libellules (72456709) »



> C'est un chemin d'accès privé
> highway=service+service=driveway+
> access=private


Je l'ai fait, j'espère n'avoir rien cassé.


> sortir de la relation

J'ai tenté... que dira Osmose ?

A+

Jacques






!! Je reposte le dernier mail de Jérôme qui est probablement passé à la 
trappe pour quelques uns d'entre nous.




la supprimer non. la mettre en voie de service ça dépend. Pour une voie de
service privé j'ai tendance à faire du cas par cas.
Si les boites aux lettres sont au niveau du portail la voie est rarement
une voie nommé sauf cas de lotissement. Le point d'adresse est
souvent unique et dans ce cas je le met sur le portail et non à l'entrée
Une partie ou la totalité de la voie peut être privée. Les service postaux
on dans ce cas un badge d'accès. Les numéros sont bien matérialisé sur les
bâtiments.

Bref on a des lieu dit complet qui sont accessible qu'en voies privé avec
des postes barrières aux entrées. L'adressage n'est pas pour autant à
l'entrée du poste barrière... Les voies sont limités à 30km/h elle sont
nommé et servent au transit (sauf accès privé).

Par défaut une voie de service n'a pas de vitesse mais pour le routing
j'irai pas y mettre plus de 20km/h et en voie privé 10 km/h sauf indication
contraire. On peut considérer que la voie de service n'est pas utilisé pour
du transit. Elle ne sert qu'à une destination finale et/ou un service
particulier (c'est un principe de routing). On évite les voies de service
pour les itinéraires rapides et équilibré sauf si c'est le seul moyen
d'arriver au POI.

Chemin : Rue des Libellules (72456629)
C'est un chemin d'accès privé
highway=service+service=driveway+access=private  ainsi pas de suppression
de l'objet en tant que tel et il faut supprimer le nom de la voie et le
sortir de la relation

portail à ajouter:
barrier=gate+access=private

Pour les deux autres ways et les points d'adresses il faut tous mettre dans
une seule relation. C'est un extension de la voie existante
La partie présente au niveau du 22 et 24 et à découper est à mettre en
portion voie d'accès privé  highway=service+service=driveway+access=private
avec le portail qui va bien ;-)

Petite remarque sur la zone:
Les voies cyclables mentionnées autour n'en sont pas. Ceux sont des
trottoirs et il n'y a aucune signalisation à ma connaissance. Les trottoirs
abaissés c'est pour les poussettes et principalement pour les PMR. Donc il
faut tous remettre comme highway=footway et ajouter les mention d'accès
wheelchair=yes sauf si la signalisation aérienne ou au sol a évolué.
Peut-être voir avec Mickey86 
 à

la base de l'édition.

Bonne journée





Le 30/12/2019 à 23:41, marc marc a écrit :

Le 30.12.19 à 22:16, deuzeffe a écrit :

Chemin : Rue des Libellules (72456629)


Ce n'est pas une rue, mais une voie privée : elle fait partie intégrante
de la parcelle 450. Classique dans les lotissements arrangés façon
Tétris. À débaptiser et passer en highway=service ?


oui


Voire à supprimer ?


non car un jour un autre contributeur la recréera :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr





--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.


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

Re: [OSM-talk-fr] Plusieurs relations pour la même rue...

[Philippe Verdy]

Il y a aussi un cas spécial pourtant assez courant:

Il arrive que le domaine public rue soit en totalité dans une seule commune
1 et pourtant il y a des adresses d'un côté de cette rue qui ne sont
accessibles que par elle mais en fait situées sur la commune 2 voisine.
Pour y accéder, uniquement une voie privée. L'adresse appartient bien à la
commune voisine 2. Dans certains cas, la commune voisine 2 ne référence pas
la rue dans le FANTOIR, et le point d'adresse a pourtant un numéro de la
commune 1 et utilise le nom de la commune 1.

Sur les adresses postales, l'adresse mentionne alors souvent les deux
communes dans l'usage courant, avec ce numéro, ce nom de rue, le code
postal de la commune 1, le nom de commune étant "commune 1/commune 2". Mais
la Poste accepte aussi juste "commune 2" sans mentionner "commune 1".

J'ai vu de telles rues apparaître et disparaître de façon instable dans le
FANTOIR selon les sources (la DGFIP, la Poste, la CCI, ou des versions
temporaires jamais finalisées, au gré visiblemetn de certains nettoyages
automatiques...). Normalement la commune 2 aurait du créer une entrée
FANTOIR pour cette rue même si elle n'est pas sur son territoire, afin d'y
mettre au moins les points d'adresse, même si la voie publique n'est pas
sur son territoire mais déborde sur la commune voisine. C'est fait
couramment dans plein de communes mais pas encore partout.

Dans OSM, le tracé filaire des rues peut ne pas suivre non plus exactement
la frontière administrative qui oscille autour du tracé actuel qui a été
régularisé (au gré des élargissements, modifications de carrefours,
giratoires, voies cyclables/bus, parfois aussi des zigzags imposés par des
stationnements alternant à droite et à gauche pour limiter la vitesse avec
une seule voie roulante et de cours segments pour se croiser et attendre.

L'inclusion géométrique stricte des rues n'a pas beaucoup de sens sur le
filaire d'OSM ou sur les points d'adresse qui ne représentent pas seul la
surface réellement désignée par une rue FANTOIR mais inclus aussi les
propriétés attenantes. La relation "associatedStreet" ou les points
d'adresse peuvent donc avoir dans certains cas des références FANTOIR d'une
autre commune que ce que désigne la surface de la relation administrative
communale. Si on avait une définition surfacique des rues, avec des
(multi)polygones englobants, on n'aurait pas ce "problème" lié à
l'insuffisance de la représentation filaire+noeuds d'adresses.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-us] FW: US Bicycle Route 1 through Daytona Beach

[Kerry Irons]

Sam,

 

The ultimate goal of the ECGW is to be 100% off road, so you will see the ECGW 
(and local communities who are ECGW supporters) jump onto paved paths for short 
distances on occasion.  Thanks for taking care of this.  We’ll see how long it 
takes to show up first in OCM and then when RWGPS will recognize it for routing.

 

 

Kerry

 

From: Sam Ley  
Sent: Tuesday, December 31, 2019 12:25 AM
To: Kerry Irons 
Cc: talk-us 
Subject: Re: [Talk-us] FW: US Bicycle Route 1 through Daytona Beach

 

Hi Kerry,

 

That is a bit of an odd trail spur to be included in the greenway, since it 
just dodges off of Beach St, and then right back on, but maybe passing by the 
park gives some opportunity for restrooms that would ordinarily be missed. I've 
added it, and connected it to the ECG relation so it should start showing up on 
OSM driven maps soon.

 

-Sam

 

Clifford,



Paved.  The city wants the ECGW and USBR 1 to be co-designated, and the ECGW 
map (https://map.greenway.org 
 ) shows this 
bike path as being on the ECGW.

Kerry 



From: Clifford Snow mailto:cliff...@snowandsnow.us> > 
Sent: Monday, December 30, 2019 7:46 PM
To: Kerry Irons mailto:irons54vor...@gmail.com> >
Cc: talk-us mailto:talk-us@openstreetmap.org> >
Subject: Re: [Talk-us] FW: US Bicycle Route 1 through Daytona Beach

Kerry - the new cycle path has been added. See 
https://www.openstreetmap.org/#map=19/29.19623/-81.01173 

 

Do you know if it is paved or what kind of surface? Is it supposed to connect 
to the ECG, the East Coast Greenway route? From Strava it doesn't appear to?



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

Re: [OSM-talk-fr] SPAM, Re: Problème avec ID - besoin d'aide

[Philippe Verdy]

Bref:
- "08:00-19:00;12:00-14:00 off" est équivalente à  "08:00- 12:00;14:00-
19:00"
- "08:00-19:00;Sa-Su off" est équivalente à  "Mo-Th 08:00-19:00"
- "Mo-Sa 08:00-19:00;Sa 18:00-19:00 off" est équivalente à  "Mo-Th
08:00-19:00;Sa 08:00-18:00"
Tu peux tester, c'est comme ça que ça marche.
Les règles séparées par ";" sont ordonnées de façon strictes, et elles sont
TOUTES évaluées cumulativement (on ne s'arrête pas au premier "match").
"||" ne sert strictement à rien (sauf à la compatibilité avec d'anciennes
spécifications qui ne marchaient pas dans plein de cas) et équivaut au ";".



Le mar. 31 déc. 2019 à 13:17, Philippe Verdy  a écrit :

>
>
> Le mar. 31 déc. 2019 à 09:18, Jérôme Seigneuret <
> jerome.seigneu...@gmail.com> a écrit :
>
>> Le ; est une règle cumulative avec écrasement des valeurs passés.
>>
>> Si tu met Lundi au Vendredi de 10 à 20h et que tu ajoutes Mercredi de 20h
>> à 22h c'est pas cumulatif. Tu dis juste de remplacer les horaires de
>> Mercredi
>>
>
> C'est un non sens complet!
>
> L'indication: "08:00-19:00;Fr 18:00-19:00 off;Su off" indique clairement
> l'ouverture tous les jours de 8h à 19h, sauf le vendredi où ça ferme à 19h
> et le dimanche fermé.
>
>
> https://openingh.openstreetmap.de/evaluation_tool/?EXP=Mo-Fr%2010%3A00-20%3A00%3B%20We%2020%3A00-22%3A00=48.84991979995=2.6370411=0=157773336_value=Mo-Fr%2010%3A00-20%3A00%3B%20We%2020%3A00-22%3A00
>
>
> L'interprétation est bien cumulative et se fait dans l'ordre, chaque règle
> séparée par ";" modifiant les précédentes.
>
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Negozio abbigliamento sportivo brand unico.

[Francesco Ansanelli]

Ciao Simone,

Io farei:

shop=clothes
clothes=sports

Vedi wiki:
https://wiki.openstreetmap.org/wiki/Tag:clothes%3Dsports

Se non c'è un'insegna:
name=Montura
brand=Montura

Se hai fatto un acquisto, valuta operator e ref:vatin per ragione sociale e
partita IVA.

Buon mapping
Francesco

Il mar 31 dic 2019, 12:37 liste DOT girarsi AT posteo DOT eu <
liste.gira...@posteo.eu> ha scritto:

> Dovrei taggare un negozio che vende abbigliamento sportivo, e
> dall'esterno non vedo articoli sportivi come sci, palloni, o altri
> accessori.
>
> Al momento l'ho taggato come shop=sports, però non mi sembra adeguato,
> la vendita è solo abbigliamento di una sola marca, che io sappia.
>
> Il negozio è questo al link:
>
>
> https://www.montura.it/it/alpstation_store/montura-shop/montura-store-borgo-valsugana.php
>
>
> --
> _|_|_|_|_|_|_|_|_|_
> |_|_|_|_|_|_|_|_|_|_|
> Simone Girardelli
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] SPAM, Re: Problème avec ID - besoin d'aide

[Philippe Verdy]

Le mar. 31 déc. 2019 à 09:18, Jérôme Seigneuret 
a écrit :

> Le ; est une règle cumulative avec écrasement des valeurs passés.
>
> Si tu met Lundi au Vendredi de 10 à 20h et que tu ajoutes Mercredi de 20h
> à 22h c'est pas cumulatif. Tu dis juste de remplacer les horaires de
> Mercredi
>

C'est un non sens complet!

L'indication: "08:00-19:00;Fr 18:00-19:00 off;Su off" indique clairement
l'ouverture tous les jours de 8h à 19h, sauf le vendredi où ça ferme à 19h
et le dimanche fermé.

https://openingh.openstreetmap.de/evaluation_tool/?EXP=Mo-Fr%2010%3A00-20%3A00%3B%20We%2020%3A00-22%3A00=48.84991979995=2.6370411=0=157773336_value=Mo-Fr%2010%3A00-20%3A00%3B%20We%2020%3A00-22%3A00


L'interprétation est bien cumulative et se fait dans l'ordre, chaque règle
séparée par ";" modifiant les précédentes.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Negozio abbigliamento sportivo brand unico.

[liste DOT girarsi AT posteo DOT eu]

Il 31/12/19 12:44, scratera ha scritto:
> ..io faccio così
> https://www.openstreetmap.org/changeset/77231761
> 
> 

outdoor l'avevo pensato, ma mi sa troppo generico, comunque penso sia
meglio di sports.

Per adesso adeguo come te, poi si vedrà le opinioni degli altri se ci sono.


-- 
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|
Simone Girardelli

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

[OSM-talk-fr] absence de BAN dans BANO

[marc marc]

Bonjour,

Quelle est la raison pour ne pas intégrer la BAN Odbl dans BANO ?
Dans certaines commune, BANO est pauvre, par ex Ceyzérieu 01073
Bano ne contient même pas l'adresse de la mairie
et de nombreuses voies "sans adresse" dans BANO
ont des adresses dans la BAN.
ex Rue de Bourbouillon

il parait qu'elle ne serra plus publiée à partir de demain :(
p'tre que Christian en ferra un archivage :)

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

Re: [OSRM-talk] Map matching for live data-streams, one point at a time

[Alex R]

Hi everybody,

I just wanted to report that we have successfully integrated OSRM, based on
Daniel's feedback in this thread.

The functionality is a part of an open source system for public transport
tracking in Moldova, you can see it on roataway.md (choose a route using
the bottom-right controls, and then wait for around 20s for the telemetry
to start arriving). The site is still work in progress, but it is  good
enough for practical purposes.

Incorrect matches still occur every now and then, so our next step is to
figure out how to produce a correct PBF file that contains only the roads
that are a part of the transport grid.

Thank you for your help!
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [Talk-it] Negozio abbigliamento sportivo brand unico.

[scratera]

..io faccio così
https://www.openstreetmap.org/changeset/77231761



--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

[Talk-it] Negozio abbigliamento sportivo brand unico.

[liste DOT girarsi AT posteo DOT eu]

Dovrei taggare un negozio che vende abbigliamento sportivo, e
dall'esterno non vedo articoli sportivi come sci, palloni, o altri
accessori.

Al momento l'ho taggato come shop=sports, però non mi sembra adeguato,
la vendita è solo abbigliamento di una sola marca, che io sappia.

Il negozio è questo al link:

https://www.montura.it/it/alpstation_store/montura-shop/montura-store-borgo-valsugana.php


-- 
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|
Simone Girardelli

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

Re: [OSM-talk-nl] OSGeo.nl/OSM-NL/QGIS-NL Nieuwjaarsborrel 12 jan 2020 Dudok, Hilversum

[St Niklaas]

Hi Just,

Bedankt voor de uitnodiging.
Bij vorige meetingen zat er nog de gelegenheid tot eten aan vast, is dat 
gewijzigd ?
Want het wordt niet genoemd, klopt mijn gevoel en mag ik dat zelf regelen ?

Nick
OSM
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [Talk-es] Unificar vías con carriles separados

[Roberto geb]

Alejandro,

separar los sentidos de la marcha cuando hay una doble línea pintada en el
suelo puede simplificar la gestión de los cruces con las otras calles
evitando añadir relaciones de giro obligatorio, etc.
Hay que tener mucho cuidado con lo que propones ya que puede acabar como
con la Gran Vía de Madrid, donde hay varias vías superpuestas con las rutas
de autobuses circulando en una u otra según su sentido pero compartidas
para el resto de vehículos. Esto genera "ruido" a los ruteadores.
A priori, no veo beneficios en fusionar ambos sentidos de circulación. De
hecho, han habido épocas en que el Ayuntamiento ha creado esas medianas
entre los sentidos y las ha llenado de árboles, por lo que además puede ser
un trabajo contraproducente.
Creo que antes de acometer ese trabajo sería prudente preguntar a los que
han trabajado la vía los motivos por los que están separados los sentidos.
En JOSM, pulsando CRTL-H puedes ver la historia de la vía y sus autores y,
pulsando sobre ellos, mandarles un correo.

Feliz Año a todos los mapeadores.

Saludos,.
Roberto

El sáb., 28 dic. 2019 a las 14:31, yo paseopor ()
escribió:

> Saludos! Doy mi opinión.
>
> Tienes mucha razón, en OSM la separación de vías debería solo marcarse si
> es física. Pero no nos engañemos, a veces es más fácil que las calles
> grandes con varios carriles estén compuestas de varios sentidos (varias
> vías).De hecho, si el ayuntamiento gastara un pelín más de dinero en poner
> bolardos, pilonas, separadores o una fina mediana de cemento ya contaría
> como separación. Por mucha razón que se tenga somos nosotros los que
> editamos, mantenemos y dibujamos el mapa , por lo tanto es nuestro
> criterio. Si quieres enfrontarte a esa complicación te animo a que lo hagas
> (pues estarás ajustando más OSM a la realidad) . Pero si no lo haces, no te
> sientas culpable, mientras todo funcione correctamente no creo que haya
> nadie en esta lista que te recrimine que esa "mediana" es solo una línea
> pintada en el suelo. Y es más, te animaría a que mejoraras cruces,
> especificaras caminos , direcciones, propiedades de aparcamiento, y muchas
> otras cosas que dan valor añadido al etiquetado de una calle que si la
> línea continua es de cemento o no.
>
> Salut i mapes
> yopaseopor
>
> On Sat, Dec 28, 2019 at 2:38 AM Alejandro S.  wrote:
>
>> ¡Hola! Una pequeña duda que me ha surgido esta semana.
>>
>> Hace cosa de un mes que empecé a intentar retocar algunas zonas de
>> Madrid, en concreto por la zona del metro de Acacias y Pirámides. He
>> visto que aquí hay muchísimas avenidas y paseos sin mediana que tienen
>> los carriles separados en el mapa (por ejemplo: Paseo Imperial o Paseo
>> de las Acacias).
>>
>> Tenía intentención de juntar ambos carriles donde no existe mediana,
>> pero no encuentro una forma sencilla de hacerlo. En Zaragoza lo
>> conseguimos con la zona del Paseo Echegaray, pero claro... Madrid cada
>> trocito de calle tiene unas 800 relaciones con líneas de bus, e ir
>> revisando todas las relaciones una a una es un currazo.
>>
>> Entonces, antes de que me enrolle más... ¿Veis correcto el intentar
>> unificar las vías sin mediana? ¿Sabéis si hay alguna forma que sea más o
>> menos sencilla? Suelo usar JOSM para editar; no sé si con alguna otra
>> herramienta puede ser más sencillo el proceso, o si conviene simplemente
>> dejarlo estar.
>>
>> Gracias!
>>
>> Un saludo,
>> Yonseca.
>>
>>
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>


-- 
Saludos,

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

Re: [OSM-talk-fr] Plusieurs relations pour la même rue...

[Jacques Lavignotte]

Je vais aller voir sur place.



!! Je reposte le dernier mail de Jérôme qui est probablement passé à la 
trappe pour quelques uns d'entre nous.




la supprimer non. la mettre en voie de service ça dépend. Pour une voie de
service privé j'ai tendance à faire du cas par cas.
Si les boites aux lettres sont au niveau du portail la voie est rarement
une voie nommé sauf cas de lotissement. Le point d'adresse est
souvent unique et dans ce cas je le met sur le portail et non à l'entrée
Une partie ou la totalité de la voie peut être privée. Les service postaux
on dans ce cas un badge d'accès. Les numéros sont bien matérialisé sur les
bâtiments.

Bref on a des lieu dit complet qui sont accessible qu'en voies privé avec
des postes barrières aux entrées. L'adressage n'est pas pour autant à
l'entrée du poste barrière... Les voies sont limités à 30km/h elle sont
nommé et servent au transit (sauf accès privé).

Par défaut une voie de service n'a pas de vitesse mais pour le routing
j'irai pas y mettre plus de 20km/h et en voie privé 10 km/h sauf indication
contraire. On peut considérer que la voie de service n'est pas utilisé pour
du transit. Elle ne sert qu'à une destination finale et/ou un service
particulier (c'est un principe de routing). On évite les voies de service
pour les itinéraires rapides et équilibré sauf si c'est le seul moyen
d'arriver au POI.

Chemin : Rue des Libellules (72456629)
C'est un chemin d'accès privé
highway=service+service=driveway+access=private  ainsi pas de suppression
de l'objet en tant que tel et il faut supprimer le nom de la voie et le
sortir de la relation

portail à ajouter:
barrier=gate+access=private

Pour les deux autres ways et les points d'adresses il faut tous mettre dans
une seule relation. C'est un extension de la voie existante
La partie présente au niveau du 22 et 24 et à découper est à mettre en
portion voie d'accès privé  highway=service+service=driveway+access=private
avec le portail qui va bien ;-)

Petite remarque sur la zone:
Les voies cyclables mentionnées autour n'en sont pas. Ceux sont des
trottoirs et il n'y a aucune signalisation à ma connaissance. Les trottoirs
abaissés c'est pour les poussettes et principalement pour les PMR. Donc il
faut tous remettre comme highway=footway et ajouter les mention d'accès
wheelchair=yes sauf si la signalisation aérienne ou au sol a évolué.
Peut-être voir avec Mickey86 
 à

la base de l'édition.

Bonne journée





Le 30/12/2019 à 23:41, marc marc a écrit :

Le 30.12.19 à 22:16, deuzeffe a écrit :

Chemin : Rue des Libellules (72456629)


Ce n'est pas une rue, mais une voie privée : elle fait partie intégrante
de la parcelle 450. Classique dans les lotissements arrangés façon
Tétris. À débaptiser et passer en highway=service ?


oui


Voire à supprimer ?


non car un jour un autre contributeur la recréera :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr



--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.


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

Re: [OSM-talk-fr] SPAM, Re: Problème avec ID - besoin d'aide

[Jérôme Seigneuret]

Le ; est une règle cumulative avec écrasement des valeurs passés.

Si tu met Lundi au Vendredi de 10 à 20h et que tu ajoutes Mercredi de 20h à
22h c'est pas cumulatif. Tu dis juste de remplacer les horaires de Mercredi
Dans ce cas il faut utiliser le *|| *et non* ; *

L'évaluation se fait de gauche à droite Si on ajoute un nouveau sélecteur
celui-ci surchage les valeur précédente ou ajoute des horaires non
précédemment défini pour le jour en question.
Même si tu spécifie des plages horaire le selecteur c'est le jour complet
donc si tu ajoutes des nouveaux horaires c'est l'horaire de la journée
complète qui est réévalué.
Le double pipe à un comportement cumulatif des plages non couvertes

*voici les exemples*
Mo-Fr 10:00-20:00; We 20:00-22:00
https://openingh.openstreetmap.de/evaluation_tool/?EXP=Mo-Fr%2010%3A00-20%3A00%3B%20We%2020%3A00-22%3A00=48.84991979995=2.6370411=0=157773336_value=Mo-Fr%2010%3A00-20%3A00%3B%20We%2020%3A00-22%3A00


Mo-Fr 10:00-20:00|| We 20:00-22:00
https://openingh.openstreetmap.de/evaluation_tool/?EXP=Mo-Fr%2010%3A00-20%3A00%7C%7C%20We%2020%3A00-22%3A00=48.84991979995=2.6370411=0=157773336_value=Mo-Fr%2010%3A00-20%3A00%3B%20We%2020%3A00-22%3A00


Maintenant comme je l'ai présenté précédemment il est possible de coupler
les séparateurs ; et tu peux surement améliorer ma proposition ou corriger
la tienne en exploitant || et en testant ;-)
Bonne journée

Le mar. 31 déc. 2019 à 00:37, Philippe Verdy  a écrit :

>
>
> Le lun. 30 déc. 2019 à 21:02, Jérôme Seigneuret <
> jerome.seigneu...@gmail.com> a écrit :
>
>> Salut,
>> "Journée continue"  n'est pas nécessaire si l'on utilise le mot clé
>> "off". Attention YoHours ne prend pas en compte toute la syntaxe de
>> opening_hours
>> exemple complet pour les vacances
>>
>> https://openingh.openstreetmap.de/evaluation_tool/?EXP=SH%2010%3A00-18%3A00%3B%20SH%20Sa%2CSu%2013%3A00-15%3A00%20off=48.84991979995=2.6370411=0=1577733402192
>>
>>
>> @Philippe l'ajout d'un sélecteur écrase la valeur précédente donc tu va
>> avoir un problème sur le mercredi et sur le jeudi. Dans ton cas, jeudi ne
>> sera ouvert que de 20h à 21h et Mercredi de 11h30 à 11h45
>> Il faut aussi ajouter PH off pour une fermeture les jours fériés si c'est
>> le cas.
>>
>
> Non, chaque valeur listée vient modifier les valeurs précédentes dans les
> plages horaires indiquées; les règles sont cumulatives, et ordonnées, mais
> dans ce cas il n'y a même pas d'écrasement, une première règle indique la
> plage "standard" du lundi au vendredi, les autres pour les jours
> particuliers viennent modifier encore ce qui est défini. Quand on "parse"'
> les règles au début la règle par défaut est "off" partout, chaque règle ne
> modifie que les plages indiquées.
>
> Mais que penser de ma proposition de rendre tous les espaces facultatifs
> sauf entre 2 lettres ou entre deux chiffres dans la syntaxe existante; ce
> qui permettrait de les supprimer pour compacter encore plus (et c'est
> facile de restaurer ces espaces "implicites" entre une lettre et un
> chiffre. Je ne vois aucune règle existante où cela conduit à une ambiguïté
> quelconque.
>
> Ca peut éventuellement casser certaines analyses lexicales mais le patch
> lexical est simple à faire, on a pratiquement besoin d'aucune espace dans
> la plupart des cas (sauf par exemple "Jul-Aug off" pour indiqué "fermé en
> juillet et août" et qu'on ne peut pas compacter en "Jul-Augoff" car cette
> espace est entre deux lettres). C'est pas une révolution, mais au moins si
> ça peut aider à passer la limite des 255 caractères par valeur de tag...
>
>

-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Plusieurs relations pour la même rue...

[Jérôme Seigneuret]

la supprimer non. la mettre en voie de service ça dépend. Pour une voie de
service privé j'ai tendance à faire du cas par cas.
Si les boites aux lettres sont au niveau du portail la voie est rarement
une voie nommé sauf cas de lotissement. Le point d'adresse est
souvent unique et dans ce cas je le met sur le portail et non à l'entrée
Une partie ou la totalité de la voie peut être privée. Les service postaux
on dans ce cas un badge d'accès. Les numéros sont bien matérialisé sur les
bâtiments.

Bref on a des lieu dit complet qui sont accessible qu'en voies privé avec
des postes barrières aux entrées. L'adressage n'est pas pour autant à
l'entrée du poste barrière... Les voies sont limités à 30km/h elle sont
nommé et servent au transit (sauf accès privé).

Par défaut une voie de service n'a pas de vitesse mais pour le routing
j'irai pas y mettre plus de 20km/h et en voie privé 10 km/h sauf indication
contraire. On peut considérer que la voie de service n'est pas utilisé pour
du transit. Elle ne sert qu'à une destination finale et/ou un service
particulier (c'est un principe de routing). On évite les voies de service
pour les itinéraires rapides et équilibré sauf si c'est le seul moyen
d'arriver au POI.

Chemin : Rue des Libellules (72456629)
C'est un chemin d'accès privé
highway=service+service=driveway+access=private  ainsi pas de suppression
de l'objet en tant que tel et il faut supprimer le nom de la voie et le
sortir de la relation

portail à ajouter:
barrier=gate+access=private

Pour les deux autres ways et les points d'adresses il faut tous mettre dans
une seule relation. C'est un extension de la voie existante
La partie présente au niveau du 22 et 24 et à découper est à mettre en
portion voie d'accès privé  highway=service+service=driveway+access=private
avec le portail qui va bien ;-)

Petite remarque sur la zone:
Les voies cyclables mentionnées autour n'en sont pas. Ceux sont des
trottoirs et il n'y a aucune signalisation à ma connaissance. Les trottoirs
abaissés c'est pour les poussettes et principalement pour les PMR. Donc il
faut tous remettre comme highway=footway et ajouter les mention d'accès
wheelchair=yes sauf si la signalisation aérienne ou au sol a évolué.
Peut-être voir avec Mickey86   à
la base de l'édition.

Bonne journée


Le lun. 30 déc. 2019 à 23:41, marc marc  a
écrit :

> Le 30.12.19 à 22:16, deuzeffe a écrit :
> >> Chemin : Rue des Libellules (72456629)
> >
> > Ce n'est pas une rue, mais une voie privée : elle fait partie intégrante
> > de la parcelle 450. Classique dans les lotissements arrangés façon
> > Tétris. À débaptiser et passer en highway=service ?
>
> oui
>
> > Voire à supprimer ?
>
> non car un jour un autre contributeur la recréera :)
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr