Re: [Talk-dk] Fejl 500 på SDFE flyfoto i JOSM?

[Hans Gregers Petersen]

Ohøj alle,

Der skulle gerne være gang i vores cluster igen - en disk var løbet
fuld hurtigere end mit oprydningsscript kunne nå at slette.

Bedste hilsner,

Gregers

Den lør. 7. sep. 2019 kl. 08.21 skrev Michael Andersen
:
>
> Linje fra terminalvindue hvorfra jeg kører JOSM:
>
> 2019-09-07 07:36:45.189 INFO: GET https://osmtools.septima.dk/mapproxy/tiles/
> 1.0.0/kortforsyningen_ortoforaar/EPSG3857/17/68718/41364.jpeg -> HTTP_1 500
> (14 B)
>
> lørdag den 7. september 2019 08.09.57 CEST skrev Hans Gregers Petersen:
> > Hej Michael,
> >
> > Er det gennem vores tjeneste (osmtools.septima.dk) eller direkte på SDFEs
> > wms?
> >
> > /Gregers
> >
> > fre. 6. sep. 2019 kl. 14.47 skrev Michael Andersen <
> >
> > openstreet...@stofanet.dk>:
> > > Ca den sidste uges tid har jeg fået et stigende antal "Fejl 500" når jeg
> > > forsøger at zoome ind på områder i JOSM, hvilket gør at mange områder er
> > > temmelig grynede og praktisk taget uanvendelige. Jeg kan ikke lige huske
> > > hvorledes man melder fejl. Kan nogen hjælpe?
> > >
> > > Mvh Hjart
> > >
> > >
> > >
> > > ___
> > > Talk-dk mailing list
> > > Talk-dk@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/talk-dk
>
>
>
>
>
> ___
> Talk-dk mailing list
> Talk-dk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-dk

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

Re: [Talk-dk] Fejl 500 på SDFE flyfoto i JOSM?

[Hans Gregers Petersen]

Hej Michael,

Er det gennem vores tjeneste (osmtools.septima.dk) eller direkte på SDFEs
wms?

/Gregers

fre. 6. sep. 2019 kl. 14.47 skrev Michael Andersen <
openstreet...@stofanet.dk>:

> Ca den sidste uges tid har jeg fået et stigende antal "Fejl 500" når jeg
> forsøger at zoome ind på områder i JOSM, hvilket gør at mange områder er
> temmelig grynede og praktisk taget uanvendelige. Jeg kan ikke lige huske
> hvorledes man melder fejl. Kan nogen hjælpe?
>
> Mvh Hjart
>
>
>
> ___
> Talk-dk mailing list
> Talk-dk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-dk
>
___
Talk-dk mailing list
Talk-dk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-dk] Rettelser til DAR og OISfixes

[Hans Gregers Petersen]

>
> Tak for forklaringen.
> Men kunne vi ikke ignorere den slags adresser når vi importerer til OSM?

Der er desværre fortsat en del valide adresser (små 300.000), der er
UF-adresser.
Men jo på sigt vil det formodentligt give mening alene at se på TK, TD
og TN - og for nu kan man bruge det i tvivlstilfældene (som dit
eksempel).

Bedste hilsner,

Gregers

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

Re: [Talk-dk] Rettelser til DAR og OISfixes

[Hans Gregers Petersen]

Hej Niels,

> Der er i alt ikke gjort et stort arbejde for at rydde op i samme
> adresse i forskellige postnumre:
>
> https://www.openstreetmap.org/node/1364214878
> https://www.openstreetmap.org/node/341019079

Der er også gjort et stort stykke arbejde dér (blandt andet med hjælp
fra undertegnede og mine kolleger) - man forsøger ret aktivt at
koordinere/forhindre, at kommuner kommer til at bruge samme husnumre
på samme "navngivne vej" (fx "Kongevejen", "Frederiksberg
Allé"/"FrederiksbergAlle" og andre der går gennem flere kommuner og
postnumre. Det er dog nemmere at forhindre nye fejl end at rette op på
de (trods alt få) fejl, der er opstået som følge af mange års
administration.

Dit eksempel er dog lovligt, og kan fx skyldes, at der forsynes varme
eller vand fra Forsyningen i Fredensborg (tidligere kommunal), til det
har man oprettet særlige adresser i en fremmed kommune.

Det hintes der også om ved at se på den tekniske standard for adressen:
Fredensborg giver "UF"  (uspecificeret eller foreløbig) -
http://dawa.aws.dk/adgangsadresser/0a3f507e-aa76-32b8-e044-0003ba298018
Helsingør giver "TK" (bygningsfacade mod vej) -
http://dawa.aws.dk/adgangsadresser/0a3f507f-e382-32b8-e044-0003ba298018
https://danmarksadresser.dk/adressedata/kodelister/teknisk-standard/

Jeg ville ikke tøve to sekunder, med at vælge at fjerne UF-adressen i
dit eksempel.

Hvis jeg kan finde tiden, vil jeg gerne se på, om vi kan smide et
eller andet på osmtools.septima.dk, der kan hjælpe med at illustrere
den slags.


Bedste hilsner,

Gregers

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

Re: [Talk-dk] Rettelser til DAR og OISfixes

[Hans Gregers Petersen]

Den tir. 13. aug. 2019 kl. 23.20 skrev Jørgen Elgaard Larsen :
> Der burde ganske vist ikke være flere veje med samme navn i samme
> postnummer - men det ved jeg af erfaring, at der er.

Adresselovens §3 stk 3 forhindrer i det mindste, at der kommer flere til.
Der er gjort et stort arbejde for at rydde op, kan du komme med et
eller flere eksempler på, hvor der er separate veje med samme navn i
samme postnummer.


/Gregers

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

Re: [Talk-dk] Opdaterede Luftfotos fra SDFE

[Hans Gregers Petersen]

Hej alle,

SDFE slap ganske rigtigt det nyeste ortofoto i går. Jeg er væk på
konference, men når jeg kommer i nærheden af en terminal, vil jeg
invalidere cachen på osmtools.septima.dk, så alle tiles er fra det nye
datasæt (så skal man ikke zoome ind, for at data er nye).


Mvh

Gregers


Den 8. nov. 2017 11:12 skrev "Michael Andersen" :

Hej

Så er der godt nyt :-). Jeg har her til formiddags kunnet konstatere at de
luftfotos fra SDFE vi ser i iD, JOSM osv nu er fra foråret 2017 (Det kan
være
nødvendigt at zoome godt ind for at få dem frem). Det sidste års tid har de
været fra foråret 2016.
Hvis man har kendskab til steder hvor der er bygget nyt eller på anden vis
sket relevante ændringer siden foråret 2016 kan det derfor være en god ide
at
se nærmere på dem nu

Mvh Hjart

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

Re: [Talk-dk] Hvilket kort i Potlatch2 og andre værktøjer til OSM

[Hans Gregers Petersen]

Hej Finn


Nu kan jeg se at det kort som Geostyrelsen havde liggende i Potlatch2, nu
er lukket helt ned, eller Ikke længere er aktiv. Jeg går ud fra at kortet
måske har ligget hos en anden bruger i en periode, så vi kunne tegne op,
eller tager jeg fejl.


Jeg har for en del år siden lavet en proxy, der kunne servere i et format,
som kunne udstille i formater, OSM-værktøjer kunne læse. Den blev for et
par år siden flyttet til osmtools.septima.dk - og det har derefter stået på
hver enkelt tile, at servicen lukkes ned.

Brug gerne Septimas osmtools-side, der serverer data på præcis samme vis
som før... :-)


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

Re: [Talk-dk] Geodanmark ortofoto 2016

[Hans Gregers Petersen]

Tak for rosen.


> Søren har helt ret. Man skal lige være opmærksom på at cachesystemerne
> (tilsyneladende både lokalt og hos Septima) kan snyde de første dage her.

Nu kun lokalt - jeg har undtagelsesvist manuelt opfrisket vores cache.


/Gregers

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

Re: [Talk-dk] Ingen Geodatastyrelsen fotos?

[Hans Gregers Petersen]

Hej alle,

Så skulle der gerne være run på igen.
Jeg har været på ferie, så jeg har ikke set, at nogen har været så ivrige,
at det rent faktisk lykkedes at løbe diskene fulde! 8-)

Det nemmeste er, at fange mig på @GregersP på Twitter. Så giv mig gerne et
pling dér, hvis det skulle ske igen. Efter min ferie vil jeg nok forøge
diskstørrelsen lidt.  :-)

/Greg


Den 10. august 2016 kl. 07.00 skrev Michael Andersen :

> Hej
>
> Er det bare mig eller...? Siden søndag har jeg ikke kunnet zoome længere
> ind
> end til hvor der på skalaen i JOSM står 50 m (pr tile?) og har derfor været
> nødt til at bruge Bing i stedet. Er der tale om et uheld som de ansvarlige
> et
> eller andet sted ikke er opmærksomme på? Jeg vil meget gerne have adgang
> til
> Geodatastyrelsen fotos igen.
>
> Mvh Hjart
>
> ___
> Talk-dk mailing list
> Talk-dk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-dk
>
___
Talk-dk mailing list
Talk-dk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-dk] Service forsvinder snart

[Hans Gregers Petersen]

Hej alle,

På den gamle gpweb-url (min private) så jeg omkring 1.5 - 2GB /døgn. Det er
selvfølgelig faldet efter den nye er kommet.  Her har vi frem til i går
haft ca 300MB / døgn. Det kommer forventeligt til at stige til samme
niveau.

Vi cacher (selvfølgelig), da lagene sjældent ændrer sig. Vi pre-seeder dog
ikke mere end de yderste niveauer. Vi har udviklet nogle indstillinger, der
giver os/jer en rigtig god hastighed, men hvor vi ikke gemmer mere end
højst nødvendigt. :-)

Det betyder dog også, at der ikke er fuld cache. Men vi bruger jo heller
ikke hele landet (forbavsende lidt faktisk). Cachen bliver sjældent større
end 5-8GB med vores indstillinger. Det selvom vi gemmer alle forespurgte
områder i en rum tid.

Udover standardlagene har vi et par udpegningslag, som vi selv beregner
hver nat og bruger til at forbedre data fra. I kan se dem på
http://osmtools.septima.dk - og I er velkomne til at bruge dem og komme med
input til dem.

Og hvorfor stiller vi det så til rådighed?
Fordi vi selv bruger osm en del, vi kortlægger selv, vi router på det, vi
beregner diverse ting og sager osv.
Ligesom med mange af de open source-projekter vi bruger og bidrager til,
får vi noget og giver noget tilbage... Det var også derfor, jeg for et års
tid siden flyttede tjenesten fra min private maskine til en, vi holder øje
med professionelt. Så vi kunne få bedre hastighed og oppetid.

Har I flere spørgsmål, så kom endelig med dem. Vi giver også gerne en kop
kaffe eller en fredagsøl på kontoret :-)

/Gregers
Den 18. jun. 2016 06:45 skrev "Michael Larsen" :

> Hej,
>
> Det behøver ikke at være dyrt, og det er heller ikke sådan at vi ikke kan
> genskabe løsningen hvis de skulle de vælge at stoppe denne meget fine
> service.
> Indtil videre syntes jeg vi blot skal sige dem tak for deres service.
>
> Jeg har selv lavet en tilsvarende løsning vha. mapproxy som fungerer som en
> cache mellem fx. JOSM og geodatastyrelsens service. Nøgleparametrene for at
> estimere en pris for hosting af sådan en løsning er hvor meget data ind/ud
> det
> danske OSM bruger og hvor meget de cacher (i princippet behøver Septima
> ikke
> cache noget). Jeg kan se, at Septima bruger AWS, så hvis de i forvejen har
> en
> instans med ledig kapacitet kan en proxy løsningen tilføjes vha fx. Docker
> næsten gratis, bortset fra trafikkosten.
>
> Måske vi kan lokke Septima til at firtælle lidt om hvor meget trafik de
> observerer og hvor meget de cacher (en fuld cache vil give os redundans)...
>
> /MichaelVL
>
> On fredag den 17. juni 2016 22.29.05 CEST Lars Gravengaard wrote:
> > Tak det virker.
> >
> > Gad vide hvor dyrt det er at hoste ? Er det en holdbar løsning ?
> >
> > Mvh
> > Lars G
> >
> > Den 17. juni 2016 kl. 21.04 skrev Soren Johannessen <
> >
> > soren.johannes...@gmail.com>:
> > > Den nye URL er lagt ind nu og hvis du opdaterer i JOSM i  >
> > > Indstillinger > TMS/WMS  og så ikonet "Genindlæs standarder" så skulle
> > > den nye proxy være der og klar til brug
> > >
> > > Bemærk at det er firmaet  Septima der er så flinke at køre en proxy
> > > server med Geodatastyrelsens lag - Så tak til Septima for denne fine
> > > service.
> > >
> > > Vh
> > > Søren Johannessen
> > >
> > > On Fri, Jun 17, 2016 at 8:26 PM, Michael Andersen 
> wrote:
> > > > Fredag den 17. juni 2016 20:21:48 skrev Lars Gravengaard:
> > > >> Hej
> > > >>
> > > >> Når jeg zoomer helt ind på billed lag Geodatastyrelsen (Denmark); i
> > > >> JOSM
> > > >> kommer teksten i rødt Service forsvinder snart
> > > >>
> > > >> Er der en løsning på dette?
> > > >>
> > > >> Mvh
> > > >> Lars G
> > > >
> > > > https://josm.openstreetmap.de/ticket/12982
> > > >
> > > > Mvh Hjart
> > > >
> > > > ___
> > > > Talk-dk mailing list
> > > > Talk-dk@openstreetmap.org
> > > > https://lists.openstreetmap.org/listinfo/talk-dk
> > >
> > > ___
> > > Talk-dk mailing list
> > > Talk-dk@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/talk-dk
>
>
>
> ___
> Talk-dk mailing list
> Talk-dk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-dk
>
___
Talk-dk mailing list
Talk-dk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-dk] GeoDanmark ortofoto 2015 er nu tilgængelig som WMS.

[Hans Gregers Petersen]

> Jeg har brugt de nye luftfotos her på Fyn.
> I den version, som ligger i Potlatch er der en fejl.
> Det drejer sig om et område på ca 2 gange 2 km nord for Brudager og øst
> for Lakkendrup (ca 5 km nordøst for Svendborg). I det område er det et helt
> forkert billede.
> Er der nogen, der eventuelt kan gøre noget ved det, så det bliver det
> rigtige billede?
>

Jeg har tjekket vores services. Det var ved GST, den var gal. De rare
mennesker på Rentemestervej er ved at tjekke op og gøre noget ved det :-)

Mvh

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

Re: [OSRM-talk] Route Optimizing

[Hans Gregers Petersen]

Hi Jonas,


 Are there any ambitions to create something like an optimization for route 
 stops?
 And when not do you know any other way to do this via rest request?


If you are thinking of the TSP -
https://en.wikipedia.org/wiki/Travelling_salesman_problem - then it is
a simple problem of I need to visit X places after each other, please
optimize the order to visit those places in. The solution is
well-described in the WikiPedia link. You can write a little
JavaScript, Python or whatever - and optimize on either distance or
time. It is fairly simple, and all you use OSRM for is getting the
costs. If you want as few calls to the OSRM-server as possible, then
have a look at the table-service  (
https://github.com/Project-OSRM/osrm-backend/wiki/Server-api#available-services
)

Best regards,

Greg


Hans Gregers Petersen
Partner, Seniorkonsulent
greg...@septima.dk
--
Septima P/S
Frederiksberggade 28, 2. tv.
1459 København K
www.septima.dk

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

Re: [Talk-dk] Export from addressnode

[Hans Gregers Petersen]

Hej Michel,


 Er kortet funktionelt (Google) eller er det en beskrivelse af en
 geografisk virkelighed? Slagteren er tilknyttet en bygning, ikke en
 adresse. Hvis kommunen omdøber gaden så flytter han ikke af den grund. Så
 jeg er mere tilhænger af at holde dem adskilt. Men Ja, det er flueknæpperi.

Jeg vil mene, at dit glimrende eksempel viser, at slagteren i Danmark netop
er tilknyttet adressen og ikke bygningen:

En adresse er (i Danmark), ikke det posten læser på brevet, men derimod et
fast objekt (datalogisk og ikke fysisk). Dette objekts id (en UUID) skifter
aldrig, men fastholdes selvom vejen deles, skifter navn, får nyt
postnummer, der bygges ny bygning på stedet osv.

Da adressen ikke afhænger af, om der er bygværk, kan man også referere
steder, der har en særlig interesse, med adresser - f.eks. har udstykninger
adresser meget tidligt (oftest fra planlægningsstadiet og altså lang tid
inden vejen er bygget fysisk).

Tilbage til slagteren: han vil (ved tilknytning til adressepunktet)
vedblive at være til, selvom han skulle vælge at rive bygningen ned og
bygge nyt.  :-)


Mvh
Gregers
___
Talk-dk mailing list
Talk-dk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-dk] Vejklassen Tertiary

[Hans Gregers Petersen]

Hej Mogens et al,

Jeg mener klart, at det netop er /forbindelses-veje/, der er tale om -
specielt når man ser på Wikien.
Det kan sikkert være en fin tommelfingerregel at se på vejbredden (og
dermed om der er striber mv), men som Allan, hans kolleger og jeg
diskuterede, er det jo netop forbindelsen, der er vigtig.

Jeg har smidt et lag på http://osmtools.septima.dk med trafikkortets
d200-lag, og på et snarligt tidspunkt vil også det lag Allan omtaler (d500)
være tilgængeligt dér.


Mvh

Gregers
(Der ejer en del af Septima P/S, og derfor i dette tilfælde har
kommercielle interesser)


Den 7. april 2015 kl. 21.02 skrev Mogens Hansen mlind...@gmail.com:


 Det ville være rigtigt godt, hvis der kunne blive bedre enighed om
 anvendelsen af 'tertiary' vs. 'unclassified'.

 Så vidt jeg har forstået, er der to meget forskellige opfattelser, som
 benyttes af forskellige kortredaktører - med heraf følgende inkonsistens
 mht den store del af vejnettet, som ikke er 'secondary' eller af højere
 rang.

 De to tolkninger af disse mindre veje kan kort beskrives som følger:

 DEN ENE TOLKNING:
 'tertiary' er veje med midterstriber. Uden midterstriber er det
 'unclassified'.

 Jeg er ikke tilhænger af denne tolkning.
 Vejdirektoratet ved måske, hvilke veje der har striber. Alle de mange
 almindelige kortlæggere ved det ikke - med mindre de på luftfoto zoomer
 helt ned og tjekker visuelt på alle de små veje - en helt uoverkommelig
 opgave - som måske så jævnligt burde gentages, da afstribningen jo kan være
 ændret.
 Desuden er der midterstriber på visse vejstrækninger med sving - mens den
 samme vej ikke har midterstriber, når det bare går ligeud.
 Endelig er denne tolkning ikke funktionel - hverken mennesker eller GPS
 kan bruge denne tolkning til planlægning eller navigation.

 DEN ANDEN TOLKNING
 'tertiary' er forbindelsesveje og vigtige tilslutningsveje - ellers er de
 'unclassified' (eller 'residential' osv.)

 Jeg er varm tilhænger af denne tolkning.
 Alle kortredaktører kan bidrage med deres lokale kendskab til gode
 forbindelsesveje, Desuden kan man ofte ved en simpel inspektion af kortet
 erkende oplagte forbindelsesveje. Denne funktionelle tolkning er nyttig -
 den kan bruges både af mennesker og GPS-navigation.
 Endelig er denne tolkning dokumenteret på wiki-siden med Map Features:
 http://wiki.openstreetmap.org/wiki/Map_Features#Highway
 Hvor alle kan finde denne vejledning:

 Highway = trunk :
 The most important roads in a country's system that aren't motorways.

 Highway = primary :
 The next most important roads in a country's system. (Often link larger
 towns.)

 Highway = secondary :
 The next most important roads in a country's system. (Often link smaller
 towns and villages.)

 Highway = tertiary :
 The next most important roads in a country's system.

 Highway = unclassified :
 The least most important through roads in a country's system – i.e. minor
 roads of a lower classification than tertiary, but which serve a purpose
 other than access to properties.

 Hvis man klikker 'tertiary' kan man bl.a. læse følgende uddybning:
 The highway=tertiary tag is used for roads connecting smaller settlements,
 and within large settlements for roads connecting local centres. In terms
 of the transportation network, OpenStreetMap tertiary roads commonly also
 connect minor streets to more major roads.

 Ved betragtning af OSM i Danmark kan man se, at 'tertiary' i vid
 udstrækning er blevet benyttet funktionelt i overensstemmelse med
 wiki-vejledningen.

 Men der er mange steder på kortet uden konsistens mht vejtype - her er et
 eksempel:

 http://www.openstreetmap.org/#map=13/55.3525/9.5904

 På dette kort ser man vejstykker, som er 'tertiary' - afbrudt af
 vejstykker, som er 'unclassified'.
 Jeg reparerer mange af den slags inkonsistente veje. Jeg vurderer om de
 gule 'tertiary' veje faktisk ser ud til at være forbindelsesveje. Her er
 det vel oplagt nok, så de hvide mellem-vejstykker bør efter min mening
 ændres fra 'unclassified' til 'tertiary', så forbindelserne bliver
 sammenhængende. Her har jeg ladet vejene være som illustration af
 inkonsistens og manglende hensyntagen til funktion.

 Her er et andet eksempel: en forbindelsesvej, som jeg (og mange andre)
 ofte benytter - fra Bramstrupvej til Højby:

 http://www.openstreetmap.org/#map=14/55.3258/10.4255

 Jeg rettede disse vejstykker fra 'unclassified' og 'residential' til
 'tertiary' fordi min GPS-navigation ledte mig ad store omveje, når jeg
 skulle til Højby eller tilbage - selv om jeg valgte 'korteste rute'.
 Efter ændringerne til 'tertiary' bliver jeg (og andre) navigeret ad denne
 oplagte forbindelsesvej.

 NB: hvis man på luftfoto zoomer ned på disse veje, vil man kunne finde
 sektioner med midterstriber og sektioner uden striber. At benytte disse til
 klassifikation giver ingen mening - efter min mening.

 Jeg mener også, at wiki-vejledningen på Map Features kan være
 tilstrækkelig.
 Hvis der er stemning for en dansk wiki-vejledning, mener jeg, at man 

Re: [Talk-dk] Vejklassen Tertiary

[Hans Gregers Petersen]

Jeg kan godt se din pointe Jørgen, jeg mener dog, at netop et trafikkort (i
modsætning til et sædvanligt teknisk kort) kan være med til at afsløre,
hvad myndighederne tænker som tertiær-veje.
Det vil også være disse veje (som regel), der ryddes for sne, som holdes
bedst vedlige osv. :-)

Anyways - vi handlede hurtigt, og også 1:5 (d500) er nu tilgængeligt
som tiles på osmtools.septima.dk - hvis nogen kan bruge dem, er vi glade.

/ Gregers
On 8 Apr 2015 14:18, Jørgen Elgaard Larsen j...@elgaard.net wrote:

  Så jeg vil mene at f.eks. den direkte vej mellem Støvring og Blenstrup
  over Fræer og Askildrup bør skifte status til tertiary Helt ud til
  rute 507.

 Ja, det virker sådan, når man kigger på kortet. Men det må i høj grad
 komme an på lokalkendskab.

 Vil en typisk lokal beboer, der skal fra Skørping til Dollerup i bil,
 vælge den rute, du beskriver - eller den sydligere rute via Hellum, Torup
 og Siem?

 Der kan være mange grunde til det ene og det andet. Nogle gange føles den
 ene bare nemmere uden at man kan sætte ord på hvorfor.

 I dette tilfælde ville jeg som sofa-mapper vælge unclassified, medmindre
 jeg havde adgang til lokalkendskab, der sagde andet.


 - Jørgen


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

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

Re: [Talk-dk] Teknisk workshop?

[Hans Gregers Petersen]

Hej alle,

Jeg har interesseret fulgt med - vi bruger meget OSM i Septima, og derfor
er jeg også begyndt at fifle lidt med nogle af de værktøjer, vi bruger (I
kender bl.a. sikkert min private MapProxy-opstilling).
Vi har derfor lavet en lille side med nogle de værktøjer vi bruger her i
biksen: http://osmtools.septima.dk/

Der kommer helt sikkert mere på - når tiden tillader det.
Muligvis kunne vi også være interesserede i at afholde den tekniske
workshop her i vores lokaler engang i foråret. :-)


De bedste hilsner,

Gregers / Septima.dk / @GregersP

Den 29. oktober 2014 kl. 18.26 skrev Jørgen Elgaard Larsen j...@elgaard.net
:

 Hej allesammen,

 De offentlige services bliver bedre og bedre. Samtidig hører jeg på
 jungletrommerne, at forskellige offentlige myndigheder så småt er ved at
 være klar til at tage imod de alle de fejl, som vi løbende finder.


 Men vores engang så fine infrastruktur kan ikke følge med:

 osm.rasher.dk- er nede/virker ikke

 osm.ter.dk   - virker vist ikke? I alle tilfælde bør importeren
vel opdaters til at bruge DAWA /aws.dk

 oisfixes.iola.dk - virker, men Ole har ikke tid til at udvide med f.x.
fejl i adresseknuder.

 Jeg klandrer ingen - det var dejlige værktøjer, og jeg er bare glad for,
 at de blev til. Men kan vi ikke gøre en indsats i vores lille community
 for at få det til at køre igen? Det behøver jo ikke at hænge på de samme
 personer.

 Hvad med, om vi organiserer en workshop, hvor vi mødes med det ene
 formål at få de forskellige services op at køre igen?

 Eventuelt kunne vi samle det på en enkelt server, som et passende udvalg
 af personer havde adgang til?

 Mvh

 - Jørgen


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

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

Re: [Talk-dk] Adresseknuder

[Hans Gregers Petersen]

Hej alle,

Vi arbejder jo med adresser til dagligt, og har derfor lidt input, som
jeg synes er værd at tage i betragtning.

 On 10/28/2014 09:57 PM, Lars Gravengaard wrote:
 En ruin kan vel godt have en adresse, men hvis der slet ikke er noget
 tilbage, synes jeg også at adressen skal slettes.

Kort fortalt: I Danmark har vi valgt at adressesætte en masse ting,
bl.a. fordi ikke kun traditionelle beboelseshuse kan være værd at
stedfæste. Der er derfor mere i en adresse end en postkasse - tænk
f.eks. på idrætspladsen, vindmøllen mv, som alle kan være værd at
kunne referere til som sted (adresse), men næppe værd at sende post
til. :-)

Det kan også være værd at huske at tiden mellem luftbillede og
adressesætning kan være lang - kommunens BBRkontor adressesætter
formodentligt så snart du går i gang med at bygge, hvor der snildt kan
gå op til et par år eller tre førend luftfotos opdateres.


Mvh

Gregers

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

Re: [Talk-dk] Noget helt andet

[Hans Gregers Petersen]

 Må jeg foreslå at en af os skriver officielt på vegne af fællesskabet og
 forklarer situationen. En vigtig besked må være, at såfremt de ikke retter
 ind (hvilket er meget let), ser vi os nødsaget til at blokere deres server
 uden yderligere varsel.

Jeg synes, det er en dårlig idé at true - især når det er noget som vi
på ingen måde kan udføre.
Hvordan skulle vi kunne lukke for DanBoligs servere - eller for deres
adgang til en privat service (MapBox)?

Fra DanBoligs synspunkt er jeg ret sikker på, at de mener, de har købt
et produkt af MapBox, som de har kundeforhold til. DanBolig kan - i
princippet - være ligeglade med hvem MapBox køber data af, så længe
de overholder deres aftale med deres leverandør.


Mvh

Gregers

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

Re: [Talk-dk] Geodatastyrelsens luftfoto via Proxyserver - et par nye oplysninger

[Hans Gregers Petersen]

Hej alle,

 Jeg har brugt de nye overflyvningsbilleder i nogen tid, og specielt ved
 naturområder er de fantastske. De er nemlig taget i det tidlige forår inden
 der kom blade på træerne. Det betyder at man kan se stier, vandløb og
 skovveje, som man ellers ikke kan se på f.eks. Bing, fordi der her er blade
 på træerne.

Forskellen mellem disse billeder og Google/Bing osv. er at disse
billeder er _beregnet_ til kortlæning (ikke ortofotoet som sådan, men
de rå billeder). Det vil sige at vi flyver dem før løvspring, så der
kan ses så meget som muligt. Det vil også sige, at nøjagtigheden
hvormed billederne optages som regel er meget højere end for et det
er pænt-ortofoto, der optages om sommeren så det ser så kønt ud som
muligt.

 Jeg er dog lidt bekymret for, om en privat server kan stå for belastningen,
 når der kommer flere brugere på. Tror I ikke det vil være bedre at finde en
 sponsor, og så lave en Amazon server?

 Men ellers tusind tak til Gregers og Søren for initiativet.

Nu er det jo aldrig sjovt, når der står men ;-)
Jeg vælger at tage det dog positivt, der er som regel meget lidt tryk
på CPUen på en tilecache og jeg har løbende nedgraderet den
reserverede CPU og memory til min demo-opsætning. Det er derfor også
mit indtryk, at der er et stykke vej førend vi er nødt til at flytte
til noget andet...

Mvh

Gregers

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

Re: [OSRM-talk] Beginner question: default car profile and tracktype/smoothness/surface

[Hans Gregers Petersen]

Hi Fernando,

 I've always wondered if there are any plans taking surface
 type/quality into account in the default profiles. I live in a
 developing country (Brazil) with poorly maintained roads and these
 conditions make a big difference at the beginning and at the end of
 many routes if ignored.

I do not know about the plans regarding the default profile, but I
successfully used a simple factor approach to surfaces when doing
our routing on bicycle paths here in Denmark.
For instance setting the following in the LUA profile:

-- How much does speed depreciate by surface
surface_factors = {
[unpaved] = 0.8,
[gravel] = 0.8,
[cobblestone] = 0.8,
[dirt] = 0.8,
[earth] = 0.8,
[sand] = 0.8,
[cobblestone:flattened] = 0.9,
[compacted] = 0.9,
[fine_gravel] = 0.9,
[wood] = 0.9
}

and then later adjuste the speed accordingly:

-- Surface tag
local surfacetag = way.tags:Find(surface)

-- Surface factor
if surface_factors[surfacetag] then
way.speed = way.speed * surface_factors[surfacetag]
way.backward_speed = way.backward_speed * surface_factors[surfacetag]
end



Best regards,

Greg



Hans Gregers Petersen
Partner, Senior Consultant
www.septima.dk

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

Re: [Talk-dk] iD editoren virker også med Geodatastyrelsens luftfotos

[Hans Gregers Petersen]

Hej alle,

 Bemærk at hvis der kommer for meget trafik så har Gregers taget det
 forebehold at lukke denne service. Men Gregers mener godt at Mapproxy
 kan klare 20-30 personer om dagen i trafik.

For lige at gøre det helt klart: _produktet_ MapProxy sagtens klare
mere - jeg har brugt det professionelt i store opsætninger, ligesom
det driver tilecaches for en række store sites (se mapproxy.org).
Jeg hoster dog løsningen på en bette, delt og virtuel server hos
WebFaction, så det er denne maskines ringe kraft og plads, der sætter
begrænsningerne. 20-30 personer skulle dog ikke  være noget problem
overhovedet. Jeg vil dog ikke love jer noget, som jeg senere måtte
trække tilbage.  :-)

For nuværende er det bare om at boltre sig, og håbe på at GST laver
TMS på Kortforsyningen på et tidspunkt - det er trods alt ikke kun i
OSM-regi det gør livet lettere.


/Gregers

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

Re: [Talk-dk] Til orientering - Nye luftfotos fra Geodatastyrelsen

[Hans Gregers Petersen]

Hej folkens,


 Desværre kan brugere af den nye iD editor eller Potlatch 2 ikke kalde
 luftfotos fra Geodatastyrelsen - Det vil kræve en TMS (Tile Map
 Server) service fra Geodatastyrelsen, hvilket de ikke har på nuværende
 tidspunkt af luftfotos. Jeg ved ikke om iD i fremtiden måske vil have
 en WMS mulighed, derved vil iD kunne bruges.

Jeg har smidt en test-cache op, der i potlatch kan tilgås via
pseudo-TMS med flg url-skema:
http://mapproxy.gpweb.dk/tiles/1.0.0/kortforsyningen_ortoforaar/EPSG3857/$z/$x/$y.jpeg

Bemærk at der er tale om en test, det kører på en relativt lille
virtuel server. Jeg garanterer derfor ikke for levetid eller
hastighed. (Bliver det positivt modtaget og skal jeg ikke bruge
maskinen til andet, forsætter den nok med at leve).

Data requestes af cachen direkte hos Kortforsyningens orto_foraar-lag
- og jeg cacher tiles i et stykke tid (lige nu en måned), så det går
pænt hurtigt når først den er seeded (efter første besøg i et område).
Lige nu er der vandmærket nogle af tilene med en (forhåbentlig) ikke
så indgribende copyright statement, af hensyn til GSTs betingelser.

Jeg hører gerne jeres kommentarer mv.


Mvh

Gregers

(Til de interesserde er det mapproxy-baseret, se http://mapproxy.org)

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

Re: [OSRM-talk] Making progress on dumping pgRouting tables to OSRM

[Hans Gregers Petersen]

Hi Steve,

We have succesfully used python (urllib2 and simplejson libs) for the HTTP
connection to OSRM.
We have gotten good response times - especially (of course) when PostgreSQL
and OSRM are both on the same server.

/Greg



*Hans Gregers Petersen*
Partner, Seniorkonsulent
greg...@septima.dk
--
Septima P/S
Larsbjørnsstræde 3
1454 Kbh K
www.septima.dk
Tlf: +45 7230 0672
Cvr: 34900841


On 15 November 2013 03:25, Stephen Woodbridge wood...@swoodbridge.comwrote:

 Antonio,

 Thank you for the feedback on CURL, and the other references.

 I kind of look at the development path as get it working then figure out
 how to make it fast. Get it working allows use to validate the approach,
 but having feedback like this is great so we can avoid the same issues
 others have already discovered.

 I'll have to read up on the apache httpclient stuff. I have never seen
 that before.

 Did you write a wrapper for your requests to OSRM via httpclient? Can you
 share that?

 Thanks,
   -Steve


 On 11/13/2013 4:03 PM, Antonio Moratilla Ocaña wrote:

 Hi Stephen

 Only two notes that may help you with your plan:
 I've been working on using OSRM from a web service, and i've learned
 OSRM doesn't perform so good when queried with curl (Ok, it's not OSRM
 problem, but curl: it need to setup a route and connection to the
 server, and it takes time, and usually you don't go concurrent here). In
 my problem, i've been using apache commons httpclient in a concurrent
 fashion (http://hc.apache.org/httpcomponents-client-4.3.x/index.html ,
 http://hc.apache.org/httpcomponents-client-4.3.x/httpclient/examples/org/
 apache/http/examples/client/ClientMultiThreadedExecution.java),
 so connections didn't get released: I was able to reach up to 700
 request por second to my test server, but when used with curl (called
 from java), I couldn't go above 20 request per second.

 On the distance matrix topic, I remember Dennis talking about it some
 time ago, and, if i'm correct, he said he had implemented a really
 efficient method for matrix calculation using some clever ideas with
 OSRM internal data representation. He said that code was not open source
 (maybe some project/contract source code?. Later on, he said he had
 matrix calculation on target to be included on OSRM soon (maybe another
 source code version)
 https://github.com/DennisOSRM/Project-OSRM/issues/544, so it would be
 great if that feature could be added. You can also try Klopt
 (https://code.google.com/p/klopt/wiki/introduction ,
 https://github.com/keesklopt/matrix)


 Good luck!!!



 Antonio Moratilla Ocaña - antonio.morati...@uah.es
 mailto:antonio.morati...@uah.es - Despacho N334


 Profesor del Dpto. Ciencias de la Computación - http://www.cc.uah.es
 Escuela Politécnica - Informática - http://www.etsii.uah.es
 Universidad de Alcalá - http://www.uah.es


 2013/11/13 Stephen Woodbridge wood...@swoodbridge.com
 mailto:wood...@swoodbridge.com


 On 11/13/2013 12:27 PM, Emil Tin wrote:


 Hi Stephen, Sound like very interesting work, conencting pgRouting
 and OSRM. I'm afraid I can't help you with your current problem,
 but
 I'm sure Dennis can.

 Emil


 Hi Emil, Dennis,

 Sorry, cross-posted to pgRouting-dev

 So this is kind of my rough plan. I have looked into how to do the
 various pieces and now it is just a matter of find some time to do
 the code and testing.

 1. build a pgr2osrm tool that will dump a pgRouting topology into an
 OSRM intermediate file that can be built with osrm-prepare. This is
 the piece that I'm working on at the moment.

 2. setup a local osrm-routed (should be trivial)

 3. code postgresql stored procedures to talk to osrm-routed using
 libcurl

 4. write stored procedures like:
 point = osrm_locate(point)
 point = osrm_nearest(point)

 jsontext = osrm_viaroute(point[], alt, instruction, zoom)
 status = osrm_getRouteStatus(jsontext);
 polyline = osrm_getRouteGeometry(__jsontext, alt)
 instructions[] = osrm_getRouteInstructions(__jsontext, alt)


 distancematrix[][] = osrm_dmatrix(points[])
 distancerow[] = osrm_one2many(point, points[]

 To support this, it would be great if Dennis had time to add two
 methods to osrm-routed like:

 http://server:5000/dmatrix?__lat=

 http://server:5000/dmatrix?lat=latlon=lon...
 http://server:5000/one2many?__slat=
 http://server:5000/one2many?slat=start_latslon=start_
 __lonlat=latlon=lon...


 where the list of points are the arguments. And if the we supply say
 10 point, then we get back a 10 x 10 matrix. I can simulate this by
 making multiple calls to the server and trying to manage all the
 hints, but it would be far more efficient to just pass the array of
 points and let the server optimize caching internally. This would
 also decrease the number of requests to the server

[Talk-dk] Kortdage og OSM

[Hans Gregers Petersen]

Hej liste,

Hermed en lille rapport fra årets Kortdage-konference (se
http://www.kortdage.dk).

Der var i år ikke så mange indlæg eller hype på standene om OSM - kun
mit eget om routing på OSM-data og sammenligning med samme på FOT (
http://www.septima.dk/user_gregers/presentation/routing_paa_osm.html#/
). Foredraget blev i øvrigt rimeligt velbesøgt og resulterede i en god
lille diskussion om troværdighed mv. omkring OSM.

Det er, som jeg ser det, dog ikke negativt -nærmest tvært imod:

Dels indeholdt mange løsninger (ikke kun fra det firma jeg selv er del
af) på den ene eller anden måde data fra OSM, som en hel naturlighed.
Der var for eksempel en del produkt-eksempler, hvor baggrundskort var
tiles fra MapQuest, OSM, MapBox eller lignende.

Dels var det min opfattelse at branchen, kommuner og stat - efter en
tid hvor nogle have opfattelse af at OSM-communitiet var nørder på et
korstog for at erstatte alle offentlige data med OSM selv - er begyndt
at få et andet indtryk af OSM, og kan se hvor OSM passer ind og
supplerer vores eksisterende (hovedsagligt tekniske) kortværker.


Mvh

Gregers


PS: Som en lille illustration af tillid til crowdsourcede data, brugte
jeg i min præsentation følgende:
Gregers: Hvor mange her har indenfor det sidste år slået noget op på
Wikipedia og troet på det de læste?
(Stort set alle rakte hånden op)
Gregers: Hvor mange har så på et tidspunkt tjekket citaterne og
referencerne, for at se om det var rigtigt?
(måske 5-10% rakte hånden op)

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

Re: [OSRM-talk] How to change the routes so that it is not illegal

[Hans Gregers Petersen]

Hi Nathan,

 In Edmonds, WA the Washington State Ferry System has a dock. This Dock is
 separated by a public road from the waiting lines and the toll booths. It is
 required for people getting on the ferry docks to go through the toll
 booths.  this almost means that you have to start the ferry routing at the
 toll booths and not at the end of the dock.   That would be one way to make
 it work even though there are more roads.

Just to be clear on things, is it this route you are talking about:
http://osrm.at/5w0  ?


Best regards,

Greg

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

Re: [Talk-dk] Næstved kommunes onlinekort

[Hans Gregers Petersen]

Hej alle,

Det ser ud til at Næstved kører med en (ældre) test-version af
SpatialMap-pluginet, der ikke indeholdt det korrekte attribution-tag
til den nederste grå linie (se f.eks. nogle af de andre
baggrundskort).
Jeg vil gætte på at Næstved Kommune (og Ishøj) derfor ganske
uforvarende ikke bringer en attribution.

Vi* var i Grontmij meget opmærksomme på at give attribution i det
endelige OSM-modul, blandt andet fordi vi var meget begejstrede over
tankerne bag OpenStreetMap - hele idéen med at lave en UTM32-baseret
OSM-service, var også netop at få de gode data i spil i kommuner og
forvaltninger, så data blev bedre til alles glæde. Som det kan ses på
http://demo33da.spatialsuite.com har modulet - i al fald i de nye
produktionsversioner - en attributering med link til
copyright-beskrivelsen.


Mvh

Gregers


*: Jeg er en af fædrene til denne service hos Grontmij, men arbejder
der ikke længere.

6. aug. 2013 09.31 skrev Pelle Rosenbeck Gøeg pe...@goeg.dk:
 Hej,

 Ved ikke om det er nok, men der står openstreetmap under valg af
 baggrundskort i menuen til venstre.


 2013/8/6 Michael Andersen hj...@milvus.dk

 Jeg kan ikke få øje på nogen attribution (hvad hedder det på dansk?) og
 der er også foretaget et par mindre ændringer (se noterne ved Toksværd
 http://openstreetmap.org/?lat=55.24892lon=11.87133zoom=15layers=Q) som
 ikke findes i vores officielle data.



 Begge dele er vist i strid med vores copyright.





 Tirsdag den 6. august 2013 08:24:12 skrev Pelle Rosenbeck Gøeg:

 Hej,


 Jep, ser det samme... Det er Grontmij (Carl Bros) webgis de bruger, som
 bl.a. bruger osm. (http://www.spatialsuite.dk/)


 - Pelle



 On 6 August 2013 08:08, Michael Andersen hj...@milvus.dk wrote:

 Hejsa

 Prøv lige at kaste et blik på http://webkort.naestved.dk/.

 Ser i det samme som jeg gør?

 ___
 Talk-dk mailing list
 Talk-dk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-dk




 --
 Venlig Hilsen

 Pelle Rosenbeck Gøeg

 Civilingeniør i Vej- og trafikteknik

 email: pe...@goeg.dk
 telefon: 61309918
 http://www.linkedin.com/pub/pelle-gøeg/1b/8a8/168




 ___
 Talk-dk mailing list
 Talk-dk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-dk




 --
 Venlig Hilsen

 Pelle Rosenbeck Gøeg

 Civilingeniør i Vej- og trafikteknik

 email: pe...@goeg.dk
 telefon: 61309918
 http://www.linkedin.com/pub/pelle-gøeg/1b/8a8/168

 ___
 Talk-dk mailing list
 Talk-dk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-dk


___
Talk-dk mailing list
Talk-dk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-dk] Næstved kommunes onlinekort

[Hans Gregers Petersen]

Hej,

 der er også foretaget et par mindre ændringer (se noterne ved Toksværd
 http://openstreetmap.org/?lat=55.24892lon=11.87133zoom=15layers=Q) som
 ikke findes i vores officielle data.

Der er så vidt jeg kan se tale om tree, som Grontmijs OSM-renderer
renderer, hvor MapQuest-temaet ikke renderer det.
Hvis man skifter til standard-temaet på osm.org fremkommer punkterne også.

Mvh

Gregers

___
Talk-dk mailing list
Talk-dk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-dk] Status på Geodatastyrelsen s FOT citering

[Hans Gregers Petersen]

Hej Søren, alle,


 Så er lige hvad gør man med geografiske objekter der krydser
 kommunegrænserne, hvilke kommune skal krediteres her? - Det er jeg
 også ved få undersøgt.

I produktionen var/er det et krav, at alle objekter brydes ved
kommunegrænsen. Jeg er ikke sikker på om de er blevet samlet bagefter
- hvis ikke er det jo ikke det store problem at kreditere.


Mvh

Gregers

___
Talk-dk mailing list
Talk-dk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-dk

Re: [OSRM-talk] Running several OSRM instances?

[Hans Gregers Petersen]

Hi Emil, all,

I always include ProxyPassReverse - as you never know if a service
will change in the future - or if some little part of it in fact does
redirects.


Cheers,

Greg


On Thu, May 16, 2013 at 10:48 AM, Emil Tin z...@tmf.kk.dk wrote:
 Is the ProxyPassReverse needed? Isn't that for handling redirects? OSRM 
 doesn't use redirects I think.



 Med venlig hilsen

 Emil Tin
 IT- og Processpecialist
 Trafikdesign
 ___
 KØBENHAVNS KOMMUNE
 Teknik- og Miljøforvaltningen
 Center for Trafik

 Islands Brygge 37 Vær. 118
 Postboks 450
 2300 København S

 Mobil
 +45 2369 5986
 Email
 z...@tmf.kk.dk


 -Oprindelig meddelelse-
 Fra: Hans Gregers Petersen [mailto:greg...@septima.dk]
 Sendt: 16. maj 2013 09:37
 Til: Emil Tin
 Cc: osrm-talk@openstreetmap.org
 Emne: Re: [OSRM-talk] Running several OSRM instances?

 Hi Emil, all,

 We use apache with mod_proxy, and I make a setup prepared to use balancers. 
 Right now we have /car, /bicycle, etc and a default page on the standard /, 
  to avoid confusion and ensure that it is nice, explicit and easy in the code 
 to switch between engines. By preparing to use balancers, I could in the 
 future add another server transparently to let several OSRM servers work on 
 say car routing.

 # Proxy to the service behind it all
 Proxy balancer://car
 BalancerMember http://127.0.0.1:5000 max=1 retry=5

 # ... More but ignorable stuff here ...
 /Proxy

 # Add the balancer for car
 ProxyPass /car/ balancer://car/
 ProxyPassReverse /car balancer://car

 Cheers,

 Greg


 On Wed, May 15, 2013 at 7:23 PM, Emil Tin e...@tin.dk wrote:
 We would like to offer different bicycle profiles (including cargo bikes) on 
 our site http://www.ibikecph.dk, and in our mobile app.

 OSRM can't yet serve different profiles from the same instance. A workaround 
 is to run mulitple instances. Does anyone have experience with running 
 several OSRM instances on the same server?


 It imagine it would be nice to map paths or params to ports, perhaps using 
 apache rewrite_mod. Example:

 http://routes.ibikecph.dk/viaroute?...   
# = map to port 5000, OSRM instance serving normal bike routes
 http://routes.ibikecph.dk/viaroute?...profile=cargobike# = 
 map to port 5001, OSRM instance serving routes for cargo bikes



 Thanks,

 Emi Tin
 City of Copenhagen
 ___
 OSRM-talk mailing list
 OSRM-talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/osrm-talk

 ___
 OSRM-talk mailing list
 OSRM-talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/osrm-talk

___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osrm-talk

Re: [Talk-dk] Bygninger fra Frederikssund Kommune - hjælp til import

[Hans Gregers Petersen]

Rigtig godt arbejde Peter (og Jonas)!

Det er godt at se, at vores data lige så stille bliver bedre og bedre. :-)

Mvh

Gregers

1. maj 2013 03.21 skrev Peter Brodersen pe...@ter.dk:
 Hej,

 Så er der bygninger i Frederikssund Kommune på OpenStreetMap!

 Jeg prøvede en række løsninger, men ingen virkede rigtig optimale med at
 arbejde på store datasæt. I stedet fik jeg altid vakse Jonas Häggqvist
 (rasher) til at hjælpe, og han lavede en opdeling på de bygning-data, vi har
 modtaget, til henholdsvis overlappende og ikke-overlappende bygninger, i
 .osm-format med relevante tags og ID for bygningerne.

 Jeg har nu importeret (næsten) alle filerne for ikke-overlappende bygninger,
 og det er noget, der er tydeligt i hele kommunen - fx Frederikssund:
 http://www.openstreetmap.org/?lat=55.84378lon=12.05713zoom=16layers=M

 De fleste bygninger er importeret, men vi skal lige køre sammenligningen
 igen i morgen, idet OSM-serveren, der blev uploadet til, ikke altid gav en
 tilbagemelding om data var blevet modtaget korrekt. Der kan derfor stadigvæk
 mangle ca. en 5-10 % af bygningerne, men dem lægger vi ind her en af dagene.

 Derefter er der en række overlap-filer, vi nok gerne vi pudse folk til at
 kigge på. Det burde være en overkommelig opgave med fx JOSM's validator at
 sammenligne med eksisterende data og fjerne de overflødige bygninger eller
 overføre tags. Mere om det senere.

 Men ellers lader det til, at vi er ved at have fået styr på metoden på at
 sammenligne datafiler med bygninger op imod eksisterende OSM-data, så vi en
 anden gang (fx for hele landet med FOT-data med afklaret licens) kan lave en
 kæmpestor import - og samtidig lave selvstændige konflikt-filer for lige
 præcis de bygninger, som overlapper eksisterende bygninger. Så kan folk fx
 hente en pakke for et område og løse overlappet.

 Importen er i øvrigt dokumenteret på wikien:
 http://wiki.openstreetmap.org/wiki/Da:Frederikssund

 - Peter Brodersen



 2013/4/23 Peter Brodersen pe...@ter.dk

 Hej,

 For ca. en måned siden importerede jeg bygninger for Jammerbugt Kommune.

 Jeg har nu også modtaget bygninger fra Frederikssund Kommune, og jeg har
 brug for lidt hjælp til planlægning af importen.

 Jeg har allerede nu lavet en række .osm-filer til import:
 http://osm.ter.dk/data/frederikssund/osm/
 .. men der er to problemstillinger, jeg kæmper med - primært ud fra ikke
 at importere bygninger over eksisterende bygninger:

 1. Bygningerne er godt spredt over hele Frederikssund, og der skal hentes
 en stor mængde data for at tjekke, at de ikke overlapper.

 2. Der er rigtig mange bygninger tegnet ind i forvejen i Frederikssund.
 Det er i forhold til OpenStreetMap ikke en dårlig ting; tværtimod! Det
 betyder dog, at der kommer til at være noget arbejde med at overføre
 eksisterende egenskaber til de nye bygninger.

 Mit udgangspunkt (og hvad jeg har kunnet se) er, at bygningerne fra
 kommunen er bedre i forhold til præcisionen, men mangelfulde i forhold til
 evt. meta-data (butik, navn, åbningstider, wifi, etc.). Informationen fra
 kommunen er begrænset til bygning og evt. type (åben eller lukket
 gylletank/silo).

 Det betyder, at der skal tjekkes en del manuelt. Det er som sådan også en
 fin ting.

 Så spørgsmålet er, hvordan vi lettest får importeret dem alle.

 - Vi kunne gøre det i fællesskab. Eventuelt med en wiki-page, hvor folk
 bød ind på en .osm-fil, de ville importere, og efterfølgende opdaterede
 wiki-siden, så vi kan sikre, at folk ikke laver dobbelt-arbejde.

 - Jeg kunne muligvis få mit program til at sortere bygningerne i grupper,
 så hver .osm-fils bbox kun dækker et begrænset område og ikke nærmest hele
 kommunen, men det vil tage lidt tid at kode.

 - Generelt er det min holdning, at når bygningerne er mere præcise, så er
 det muligt at gå ind i fx JOSM, søge efter overlappende bygninger (via
 validatoren), fjerne alle fra kommunens datasæt og alle, der rent faktisk
 har tags på (ud over source og building=yes) og så slette de tilbageværende
 (dvs. de eksisterende bygninger i OSM, som ikke har nogen ekstra information
 lagt ind).

 - Og muligvis kunne det være fint med et godt bbox-opslag, der trækker
 alle bygninger (points, ways og ikke mindst relations) ud som grundlag. Dog,
 to bygninger i forskellige .osm-fil kan overlappe den samme bygning i dette
 udtræk, hvilket kan føre til konflikt, hvis man vælger at slette en
 eksisterende bygning ved import af én fil, og senere vælger at slette samme
 bygning igen (ud fra det statiske udtræk) ved import af en anden fil.

 Ellers nogen bud? Prøv eventuelt at hente én af .osm-filerne og tænk over,
 hvad der lige er at gøre. Det kunne være fantastisk at have nået at
 importere alle bygninger til 1. januar, hvor kommunen gør brug af en løsning
 over for borgerne, hvor de benytter OSM som baggrundslag.

 De rå filer fra kommunen er naturligvis også tilgængelige for
 interesserede:
 http://osm.ter.dk/data/frederikssund/
 Min efterbehandling til .osm-filerne omfatter blandt andet at 

Re: [Talk-dk] Licensforvirring

[Hans Gregers Petersen]

Hej Kurt, alle,

 Kommunerne og GST ejer FOT-data i fællesskab og har de samme rettigheder til 
 data.
 Kommunerne kan ikke uddele FOT-data med flere rettigheder, end de selv 
 besidder.

Jeg tror såmænd ikke folk er i tvivl dette. Det som tvivlen går på -
som jeg har forstået det - er den juridiske ordlyd af afsnittet
Kildeangivelse i Vilkår for brug af frie geografiske data.
Jeg vil tro at grunden til, at folk er mere trygge ved en eksplicit
licens fra den enkelte kommune end ved den samlede Vilkår for brug af
frie geografiske data, er punkterne 5.3, 7.1 og 7.2[1] i FOTDanmarks
vedtægter.

I praksis er det - tror jeg - nok mere en frygt for uforvarende at
komme til at overtræde noget juridisk, hvor man føler sig bedre dækket
ind af at nogen (kommunerne) eksplicit siger læg det her på OSM.


Mvh

Gregers


[1] Vedtægter for FOTDanmark, 8. oktober 2007:
5.3 Et kommunalt medlem kan inden for sit eget geografiske område
give tredjepart ret til at anvende FOT-data, herunder mod betaling.
7.1 De enkelte FOT-data ejes af de medlemmer, som har finansieret
udarbejdelsen heraf.
7.2 Medlemmerne håndhæver selv deres rettigheder til FOT-data over
for tredjemand.

___
Talk-dk mailing list
Talk-dk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-dk] min egen OSM server???

[Hans Gregers Petersen]

Hej,


 Hvis man gerne vil have sin egen OSM server, med en fuldt synkroniseret kopi
 af OSM vektor data for hele verden. Hvem skal man så spørge om råd og
 vejledning til opsætning og instalation?

Jeg har tidligere sat noget lignende op, der involverede: PostGIS,
osmosis, osm2pgsql mv (og mapnik og mapproxy).
Tag et kig på http://wiki.openstreetmap.org/wiki/Minutely_Mapnik som
jeg synes forklarer delelementerne nogenlunde (derefter er der så et
arbejde i at undersøge hver enkelt del af processen, hvis man også vil
optimere og forstå processen). Jeg kan også anbefale at se på
forskellige artikler om optimering af PostGIS-setups, da det bliver
noget af en database, man har gang i.

Desværre er der - så vidt jeg husker - ikke en super howto, og jeg fik
aldrig selv til til at skrive en.


Mvh

Gregers

___
Talk-dk mailing list
Talk-dk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-dk

Re: [OSRM-talk] Building/Running OSRM on Ubuntu 12.10

[Hans Gregers Petersen]

Hi Paul,

 I was able to follow the instructions to build and run ORSM on Ubuntu 12.10, 
 using the instruction on the Wiki for 12.04.. with the following issues..

 1. When starting the server I get an error with the 'map.osrm.timestamp' file 
 not exisiting. I did a 'touch' map.osm.timestamp
and it was then able to run.

As far as I remember, this is the same for 12.04 - at least my setup
scripts create the timestamp themselves.


 2. I used a self created/exported osm map file, and ended up with the 
 following error when accessing the web page:
 http://127.0.0.1:5000
 -
 400 Bad Request

 Input seems to be malformed close to position
 /0
 ^
 
 I'm guessing that this is actually correct, given that I haven't actually 
 asked for anything.

Sounds reasonable, at least it is the same answer you will get on
earlier versions, when you have a malformed (or missing) request.


Cheers,

Greg

___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osrm-talk

Re: [Talk-dk] Bygninger fra Frederikssund Kommune - hjælp til import

[Hans Gregers Petersen]

Hej Peter, alle,

Det er superfedt at flere og flere kommuner gerne vil med på vognen.

Det kan også være relevant at huske at FOT-bygninger - i al fald indtil de
er geokodede - hænger sammen hvor bygningerne rør-hinanden indenfor
registreringsnøjagtigheden.
Så det folk normalt vil tagge som to bygninger (der rør hinanden) med to
butikker i - vil i FOT være registreret som en enkelt bygning (med mindre
de er splittet jf. geokodning).
Jeg kan ikke huske om Frederikssund kommune har fået geokodet og lagt denne
information ind i FOT2009-databasen, hvis ikke skal der nok noget manuelt
bygningsopsplitningsarbejde til, for at kunne overføre information i
bymidte mv.

Hvis der ér geokodet, så skal man også lige huske at klippe med
kommunegrænsen, da udtræk fra FOT som regel er på en bounding box omkring
kommunen og indeholder data for kommunerne omkring (der bør nok i
virkelighende altid klippes med en kommunegrænse, da Frederikssund jo ikke
har rettighederne til naboernes data).


/Gregers



Den 23. apr. 2013 14.08 skrev Peter Brodersen pe...@ter.dk:

 Hej,

 For ca. en måned siden importerede jeg bygninger for Jammerbugt Kommune.

 Jeg har nu også modtaget bygninger fra Frederikssund Kommune, og jeg har
 brug for lidt hjælp til planlægning af importen.

 Jeg har allerede nu lavet en række .osm-filer til import:
 http://osm.ter.dk/data/frederikssund/osm/
 .. men der er to problemstillinger, jeg kæmper med - primært ud fra ikke
 at importere bygninger over eksisterende bygninger:

 1. Bygningerne er godt spredt over hele Frederikssund, og der skal hentes
 en stor mængde data for at tjekke, at de ikke overlapper.

 2. Der er rigtig mange bygninger tegnet ind i forvejen i Frederikssund.
 Det er i forhold til OpenStreetMap ikke en dårlig ting; tværtimod! Det
 betyder dog, at der kommer til at være noget arbejde med at overføre
 eksisterende egenskaber til de nye bygninger.

 Mit udgangspunkt (og hvad jeg har kunnet se) er, at bygningerne fra
 kommunen er bedre i forhold til præcisionen, men mangelfulde i forhold til
 evt. meta-data (butik, navn, åbningstider, wifi, etc.). Informationen fra
 kommunen er begrænset til bygning og evt. type (åben eller lukket
 gylletank/silo).

 Det betyder, at der skal tjekkes en del manuelt. Det er som sådan også en
 fin ting.

 Så spørgsmålet er, hvordan vi lettest får importeret dem alle.

 - Vi kunne gøre det i fællesskab. Eventuelt med en wiki-page, hvor folk
 bød ind på en .osm-fil, de ville importere, og efterfølgende opdaterede
 wiki-siden, så vi kan sikre, at folk ikke laver dobbelt-arbejde.

 - Jeg kunne muligvis få mit program til at sortere bygningerne i grupper,
 så hver .osm-fils bbox kun dækker et begrænset område og ikke nærmest hele
 kommunen, men det vil tage lidt tid at kode.

 - Generelt er det min holdning, at når bygningerne er mere præcise, så er
 det muligt at gå ind i fx JOSM, søge efter overlappende bygninger (via
 validatoren), fjerne alle fra kommunens datasæt og alle, der rent faktisk
 har tags på (ud over source og building=yes) og så slette de tilbageværende
 (dvs. de eksisterende bygninger i OSM, som ikke har nogen ekstra
 information lagt ind).

 - Og muligvis kunne det være fint med et godt bbox-opslag, der trækker
 alle bygninger (points, ways og ikke mindst relations) ud som grundlag.
 Dog, to bygninger i forskellige .osm-fil kan overlappe den samme bygning i
 dette udtræk, hvilket kan føre til konflikt, hvis man vælger at slette en
 eksisterende bygning ved import af én fil, og senere vælger at slette samme
 bygning igen (ud fra det statiske udtræk) ved import af en anden fil.

 Ellers nogen bud? Prøv eventuelt at hente én af .osm-filerne og tænk over,
 hvad der lige er at gøre. Det kunne være fantastisk at have nået at
 importere alle bygninger til 1. januar, hvor kommunen gør brug af en
 løsning over for borgerne, hvor de benytter OSM som baggrundslag.

 De rå filer fra kommunen er naturligvis også tilgængelige for
 interesserede:
 http://osm.ter.dk/data/frederikssund/
 Min efterbehandling til .osm-filerne omfatter blandt andet at indsætte de
 rigtige silo-tags på og få genereret korrekte multipolygoner for bygninger
 med huller i.

 - Peter Brodersen

 ___
 Talk-dk mailing list
 Talk-dk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-dk


___
Talk-dk mailing list
Talk-dk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-dk] Bygninger

[Hans Gregers Petersen]

19. mar. 2013 18.07 skrev Jonas Häggqvist ras...@rasher.dk:
 3. Jeg skal have eksperimenteret med forenkling af FOT data der til tider
 har alt for mange nodes (flere hundrede nodes for en silo er vildt i
 overkanten).

I al ydmyghed, vil jeg foreslå, at du negligerer dette punkt.

Der er i FOT ganske tydelige regler for registreringen, så
nøjagtigheden overholdes, og så vidt jeg husker skal siloer i
OP3-områder (udenfor byerne) overholde den almene 1 meters
nøjagtighed. Således vil punktet maksimalt afvige 1 meter fra det
faktiske fotogrammetriske punkt. På ganske store siloer, vil der
derfor kunne forekomme en del punkter - men det vigtige er at
nøjagtigheden her ikke er anderledes end for huse i samme OP (siloer
har bare desværre ofte runde geometrier - hvor vores mere
almindelige bygninger har en tendens til at være rektangulære).

Som jeg ser det er det ikke anderledes end enhver anden indtegning,
hvor nogle folk meget tydeligt overregistrerer vejmidter gennem
sving eller værre endnu indfører punkter for hver X meter på lige
strækninger.

Min pointe er, at hvis det kan spare dig/nogen noget arbejde, og hvis
det i virkeligheden er et ikke-problem (som jeg opfatter det som), så
ville jeg personligt hellere bruge tiden på noget andet end at
forenkle data. :-)


Mvh

Gregers


(Mit gæt er i øvrigt at der vil være ganske få OP1-siloer (siloer
indenfor bygrænserne), hvor registreringsnøjagtigheden i stedet er
30cm.)

___
Talk-dk mailing list
Talk-dk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-dk] FYI - Kortforsyningen er nede

[Hans Gregers Petersen]

19. mar. 2013 11.17 skrev Soren Johannessen soren.johannes...@gmail.com:
 Hej alle sammen

Ohøj,

 Hvis der er nogen af jer der ikke rigtigt har kunne få hul igennem via
 WMS til Geodatastyrelsen (fx FOT 2012 luftfotolag) i JOSM de sidste to
 dage, så skyldes det at de er nede
 http://www.gst.dk/Nyheder/kortforsyningen.htm

Tilsyneladende er bl.a. WMS via kortforsyningen.kms.dk oppe. - jeg kan
i al fald fint se skærmkortet her.


/Gregers

___
Talk-dk mailing list
Talk-dk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-dk] Import af bygninger fra Geodatastyrelsen

[Hans Gregers Petersen]

Der er kommet mange gode pointer, og jeg må - som jeg også har nævnt
her på listen før - istemme med nøjagtighedsbetragtningerne: Kurt har
helt ret I sine bemærkninger om de FOT-data. Jeg ville måske tro at
Bings ortofotos er lidt mere nøjagtige, men nu har jeg jo også siddet
i firmaet der stod for at lave de data, så der er jeg nok farvet ;-)


25. jan. 2013 00.30 skrev Jonas Häggqvist ras...@rasher.dk:
 I FOT er en hel blok af sammenhængende bygninger
 indtegnet som ét objekt, hvorimod man i OSM typisk vil dele bygningerne
 op[2].

Lige angående det her, kan der så komme endnu en udfordring: det er
rigtigt at den tekniske kortlægning i FOT foregår på denne måde - MEN
når kommunerne lige nu får foretaget såkaldt bygningsgeokodning, vil
rigtig mange af dem netop foretage opdeling i BBR-enheder (der typisk
er det folk også mapper i virkeligheden i OSM). Så nogle kommuner vil
have hele samlede bygninger - andre (flere og flere over tid) vil
have opdelte geokodede bygninger - som eksempel kan man se på Høje
Taastrup Kommune, der i FOT-databasen er geokodet og opdelt (jeg ved
så ikke hvornår de frie grunddata er udtrukket).


Mvh

Gregers

___
Talk-dk mailing list
Talk-dk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-dk] Fugro luftfotos på sydfyn, vest for Svendborg

[Hans Gregers Petersen]

Hey,

tirsdag den 8. januar 2013 skrev Peter Brodersen :

 Tjek. ECW-filen lader til at have det fint nok, også hvis man zoomer
 længere ud. Spøjst. Jeg har også prøvet at deaktivere cachen uden
 held.


Så kan vi sikkert godt finde ud af at få data til at virke med lidt
gdal-trylleri - jeg har set problemet med broken ECW et par gange før.
Du kan evt. skrive til mig privat eller på facebook, da det ikke er så
OSM-relevant.



 Nå, til gengæld har jeg fået en notits fra Post Danmark om, at der
 ligger en harddisk og venter på mig :-)


Fedt.

Mvh

Gregers
___
Talk-dk mailing list
Talk-dk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-dk] Fugro luftfotos på sydfyn, vest for Svendborg

[Hans Gregers Petersen]

7. jan. 2013 11.46 skrev Kristian Krægpøth k.kragp...@gmail.com:
 Sådan som jeg har opfattet omtalen af Geodatastyrelsens frigivelse af data
 vil det være muligt at masseimportere bl.a. bygninger til OSM.
 Hvis det er rigtigt opfattet må det være at foretrække frem for at tegne
 efter diverse luftfoto uanset om det er Fugro eller Geodatastyrelsens foto.

Det er helt sikkert at foretrække, som jeg har nævnt tidligere på
listen her, så er der milevid forskel på nøjagtigheden af de
fotogrammetrisk registrerede data (fra såkaldte stereobilleder) og
registreringer foretaget på ortofotos. Selv med meget dygtige
professionelle operatører vil nøjagtigheden være bedre.

Estimeret nøjagtighed x,y på f.eks. Fugros ortofoto vil være omkring
en billængde (på grund af orienteringen af billedernes beskaffenhed er
der områder hvor det er meget værre) - på FOT-dataene vil
registreringsnøjagtigheden i X,Y-planet være omkring 10-20 centimeter
og i Z omkring 20-30 centimeter...


Mvh

Gregers

___
Talk-dk mailing list
Talk-dk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-dk] Træer

[Hans Gregers Petersen]

5. nov. 2012 14.25 skrev Jørgen Elgaard Larsen j...@elgaard.net:

 Jeg vil ikke kalde det hærværk, men måske en mærkelig prioritering at
 indtegne enkelt-træer, men ikke huse og større træ-områder.

 Personligt ville jeg kun gide at mappe enkelttræer, der havde særlig
 betydning eller på anden måde fungerede son landkending. Men enhver sine
 lyster...

Jeg er enig med Jørgen, det er vel det vanlige med at vi ikke mapper
til renderen.
Hvis nogen har lyst til at mappe alle toiletskure i Danmark (eller
enkelttræer eller...), så fred være med det.


Mvh

Gregers

___
Talk-dk mailing list
Talk-dk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-dk] Træer

[Hans Gregers Petersen]

5. nov. 2012 14.43 skrev Uffe Kousgaard u...@routeware.dk:
 Prøv at læse beskrivelsen af tree:
 http://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree

 Der er kun få af de mappede træer, der er signifikante eller alene.


Det er nok fordi, jeg er farvet af at have arbejdet med teknisk
kortlægning, men så vidt jeg kan se, står de træer jeg udtog til
stikprøve alle alene.
I de danske kortstandarder registreres enkelttræer, såfremt der er
mere end 1 meter til nærmeste andet træ, hvis stammen er større end
20cm (mener jeg). Er der mere end et par håndfulde sådanne træer
registreres et hegn. Træerne registreres typisk hvor der er offentlig
adgang (langs veje, på pladser osv).

Der hvor det for mig ser spøjst ud her, er at nogle af træerne er i
haver osv. Det ville man ikke gøre i de rigtige tekniske kort, med
mindre de var særligt signifikante.


Mvh

Gregers

___
Talk-dk mailing list
Talk-dk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-dk] Træer

[Hans Gregers Petersen]

5. nov. 2012 15.08 skrev Uffe Kousgaard u...@routeware.dk:
 Det er også et naturligt krav, at de er signifikante:
 http://wiki.openstreetmap.org/wiki/Vegetation

Det er måske i virkeligheden her, vi har forskellige holdninger.
Min holdning til signifikant er anderledes end din, AE35s (Sørens), og Jørgens.


 Ellers ender man i denne situation, hvor stort set alle træer i bymæssig
 bebyggelse skal markeres og det er der vel ingen der har tænkt sig eller vil
 holde opdateret?

Jeg fristes til at sige, at dette er det samme for hvilken som helst
type af data i OSM.
Jeg har mappet en del, der er interessant for folk på cykel i den
gamle Sindal Kommune - men hvem ved om en shelterplads jeg har tegnet
ind nogensinde vil blive fjernet fra kortet, hvis Hjørring Kommune
nedlægger den igen...


 TK1 / TK2 / TK3 er en ganske anden standard end OSM.

Helt enig, det var en forklaring på hvorledes man i den tekniske
kortlægning (og følgelig jeg) normalt tolker
enkeltstående/alenestående træer i kortsammenhæng.


Mvh

Gregers

___
Talk-dk mailing list
Talk-dk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-dk] Data drinks i morgen aften

[Hans Gregers Petersen]

2012/10/16 Peter Brodersen pe...@ter.dk:
 Yay! Jeg regner også med at dukke op.

Slesvig?
Det tror jeg nok vi tør!

-- 
Gregers

___
Talk-dk mailing list
Talk-dk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-dk] friskfrigivede data

[Hans Gregers Petersen]

Hej Michael,


27. jun. 2012 13.59 skrev Michael Hammel m...@dcf.dk:

 Kommunerne Frederikssund, Egedal, Herlev og Ballerup har i deres samarbejde 
 Bycirkel-kommunerne frigivet FOT-data til OpenStreetMap.

Super arbejde, det er rart at se at flere og flere åbner op for lidt
af deres godtepose.


Mvh

Gregers

___
Talk-dk mailing list
Talk-dk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-dk] opening_hours

[Hans Gregers Petersen]

 Jeg ville sige
  opening_hours=Jan-Mar Mo-Su 07:00-19:00;Apr-Sep Mo-Su 07:00-22:00;Oct-Dec
 Mo-Su 07:00-19:00

Når jeg læser vejledningen på
http://wiki.openstreetmap.org/wiki/Key:opening_hours kan jeg ikke se
at kombinationen  mo-mo wd-wd hh:mm-hhmm er gyldig. Jeg ville i
øvrigt - idet åbningstiden ikke afhænger af dagen - også mene det var
en unødvendig ekstra information og derfor ville jeg nok tagge:

opening_hours=Jan-Mar 07:00-19:00;Apr-Sep 07:00-22:00;Oct-Dec 07:00-19:00

Tre personer, tre forslag :-)


/Gregers

___
Talk-dk mailing list
Talk-dk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-dk] danske udgaver af geofabrik?

[Hans Gregers Petersen]

 hej,

Hej Emil,


 jeg vil høre om i kender til firmaer eller udviklere der har erfaring med
 opsætning/drift af tile-servere? gerne også med erfaring i at udarbejde nye
 styles til mapnik.

 jeg kender til tyske geofabrik . findes der nogen lignende i danmark?

Uden det skal blive en reklame, vil jeg indskyde, at jeg selv arbejder
et sted, hvor vi netop er i gang med at udbyde OSM-data på en
Geofabrik-lignende måde…

Lige nu kører vi det i test, så vi har ikke meget offentligt
tilgængeligt info, men vi forventer snart at gå i fuld drift. Det vi
kommer til at tilbyde er fra starten er tiles og WMS i UTM32/euref89
(så danske data uden problemer kan over/underlægges) og et par andre
projektioner, med lidt forskellige opdateringsmuligheder (f.eks.
månedligt eller ”semi live”/30 min.). Vi har flere forskellige styles
på servicen, så det er også noget vi ”går og roder” med her. Jeg er
selv mest på teknikken, men jeg er da sikker på, at vi gerne tager en
uforpligtende snak med jer...


Mvh

Gregers
(Som deltager på listen som ivrig privat mapper, men arbejder hos
Grontmij – bl.a. med vores OpenStreetMap-services)

___
Talk-dk mailing list
Talk-dk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-dk