Tak for at du opdagede det. Det er den i Gravel.

Positionen kom fra fødevarestyrlsen. Men i det seneste datasæt har de helt fjernet positionen fra LeCoq, så de har åbenbart selv opdaget det.

Tak, har rettet det.

There was an access tag saying "only wednesdays" in Danish. I thought opening_hours would be more appropriate. I fixed the typo now.

Jeg har genskabt Nonno.

Asger havde faktisk tagget det meget fint.

Der er et nyt script, der finder madsteder, der er ikke er rettet i 120 dage og som ikke har et fvst:navnelbnr.

Cyan i
http://digitalfrihed.dk/restaurants/uni.html

Der er nu kun ca 70 tilbage.

Selve genoplivningen er jeg selv skyld i, formodentlig ved en merge i JOSM. Jeg har nok set at der var var et pizzasted, der manglede et navnelbnr og et lige ved siden af der havde i FVST men ikke var i OSM og ikke lværet opmærksom på de ekstra tags.

Men skriptet kan jeg godt få til at checke for fx old_fvst:navnelbnr.

I alt fald når jeg laver det næste skript, som bliver steder som har et fvst:navnelbnr, men et som ikke længere er i FVST.

Det har du ret i.
Jeg kender ikke rigtig Euro Spar.

Ser på hjemmesiden at de nu enten bliver til Meny eller Spar.

Vi har en blacklist til den slags:
https://github.com/elgaard/OpenStreetmapTools/blob/master/restaurants/blacklist.json

Og jeg modtager gerne pull requests.
Jeg synes at det er bedst at holde ikke-eksisterende ting ude af OSM databasen.

Tak.
Jeg prøver. Jeg brugte en bærbar uden en rigtig mus i dag, så er fejlraten større.

restaurant, tak

Du slår dem op FVST:

http://www.findsmiley.dk/41104
ser tom ud, så det er den forkerte/gamle.
http://www.findsmiley.dk/663684 er fra Oktober 2016.

Jeg har for længe siden tilføjet det til linkify diskussionssiden, men der er ikke sket noget. Ellers ville du bare kunne åbne det i en browser og trykke på linket.

Det er ikke altid at det virker, for nogen gange tager det lidt tid inden FVST får fjernet gamle rapporter, når et sted får nye ejere. Så kan man gå efter den nyeste rapport,

Jeg vil lave et værktøj, der finder alle madsteder med et fvst:navnelbnr, som ikke findes i FVST. Det burde kunne fange både den her slags dubletter og steder, som bare er ophørt.

Udover at jeg overså at der var en Charlies i forvejen, så opstod dubletten fordi den ikke blev fanget at matchingen på http://digitalfrihed.dk/restaurants/uni.html fordi FVST nu har kaldt den "Kloster Design/Charlys Café". Så jeg kan også prøve at forbedre matchingen.

Tak. Lige den her var nu ogsaa pga af mit eget værtøj. Jeg har ikke kunnet finde ud af at håndtere "&", og konverterer derfor til " og " i URL-en.

Men nu er jeg snart færdig med alle madsteder og checker jeg den slags igen med noget overpass-turbo.

Tak

Og nu er bygningen tagget som Monarch med en Dominos indeni. Jeg ved om det afspejler virkeligheden.

Jeg ser at seneste ændring er at en tysker har tagget Dominos med name:de="Monarch Fast Food Restaurant". Det er naturligvis forkert udover at det er tagget på det forkerte objekt, så er det jo heller ikke tysk. Og jeg tror heller ikke, at det er et navn Monarch, selv bruger. Men det kun hans 3. rettelse.

Selve ændringen er bare en opdatering af fvst:navnelbnr og den er korrekt nok.

Kontrolrapporten er for "Manarch & Domino's". Manarch må være en tastefejl. Jeg læste en kontrolrapport, den omtaler en ovn, så det lyder som Dominos.
på Monarch.dk er der et link til kontrolrapport 80376. På dominos.dk er der et link til 80157722, som redirecter til 80376. (det har irriteret mig at de har ændret nogle navnelbnr id's og jeg vidste ikke før, at jeg kunne finde de nye navnelbnr vha redirects på findsmiley.dk).

Så åbenbart er det virkelig en fælles kontrolrapport for Dominos og Monarch. Under alle omstændigheder må der skulle være både en Dominos og en Monarch der. Point ved jeg ikke hvad er.

OK. tak

Dublet af hvad?
Jeg kan ikke se en dublet, måske er det allerede rettet?

Enig. Jeg mente, at man skal passe på med at tagge til en bestemt ruter, ligesom med at tagge til en bestemt renderer. Problemer i rutere, skal ikke afhjælpes ved at rette i data.

Jeg har også bemærket nogle uheldige landuse=residential.

På fx:
highway=motorway_link
er de godt korte.

I praksis er det ret irriterende når man bruger fx OsMand når man kører på motorveje og kommer til en afkørses at den bare sige "keep right" eller "keep slightly right" eller sådan noget, når en person ville have sagt "kør af her".

Vi skal naturligvis ikke tagge til rutere og de burde nok være bedre til at forstå junction/exit/lane tags.

Men det er heller ikke nemt at se på en lille skærm i biler hvad der foregår mens man kører, når man bare kan se 7 baner, der alle bare forsætter fremad.

Nu har jeg fjernet tagget. Hvis det var gården, der havde en særlig tilladelse til at køre maskiner gennem tunnelen, skulle det have være motor_vehicle=private eller lignende.

Jeg er ret sikker på at https://agol.dk/osm/motor.png
ikke kan være rigtigt.

Hvor er der access=no på
way/257008240/history
?

Er
way/183961989

virkelig en cykelsti med "motor_vehicle=yes"?
Jeg kan se at du lige har ryddet op i området::
way/165253883

Så måske har du en mening om det.

På luftfotos ser det ikke ud som om en bil kan køre der. Måske en knallert.