[Talk-dk] pladser - helt ud til veje/bygninger?

[Emil Tin]

generelt er jeg også tilhænger af ikke at gøre osm til et teknisk grundkort, men hellere se det som en pragmatisk model . styrken ved et kort er netop at det er en simplificering af virkeligheden. det er derfor veje er tegnet som linjer, ikke som flader. kunsten er så at enes om en nogenlunde ensartet model for hvordan denne simplificering foregår, så kortet kan anvendes praktisk til fx ruteberegning.

 

ud fra dem denne betragtning giver det mening at se en plads i osm som en model, på samme måde som en linje er en model af en vejflade. hvorvidt den skal gå ud til vejen bør måske derfor afhænge af adgangen til den? hvis man lægger dem ud til vejen indikerer man vel at man kan tilgå pladsen hvor som helst fra vejen. hvis den ikke rører ved vejen kan man i stedet manuelt tilføje forbindeslinjer de steder hvor man kan tilgå pladsen.

 

@uffe. vi bruger for tiden en prototype baseret på OSRM (open source routing machine). den tillader routing på alle type af pladser, ved simpelt hen at følge kanten. det er ikke perfekt, men gør dog at pladser fungerer som forbindelser. en bedre løsning ville være at tilføje syntetiske forbindelser på tværs af pladsen (idet man husker på at pladser kan være have sjove former). optimalt set kan man forbinde alle nodes (der også er del af en way) med alle andre, men det han hurtigt bliver til mange nye linjer. en mere pragmatisk løsning kunne være at opdele/subdivide pladsen i triangler.

 

vh

emil tin

 

Fra: Uffe Kousgaard [mailto:uffe at routeware.dk] 
Sendt: 13. februar 2012 10:16
Til: OpenStreetMap Denmark
Emne: Re: [Talk-dk] pladser - helt ud til veje/bygninger?

 

Men veje er jo netop ikke fysiske midterlinier i virkeligheden?

Din beskrivelse peger mere i retning af et teknisk grundkort, som kommunerne anvender, når de præcis skal have styr på hvordan lygtepæle og mange andre detaljer skal placeres ift. hinanden. Det er sjældent tekniske grundkort man anvender til hverken ruteberegninger eller kort i større målestok (over 1:10000).

Heldigvis har man på flere områder valgt en mere pragmatisk tilgang, i erkendelse af at kortdata ikke blot skal indsamles for deres egen skyld, men faktisk anvendes til noget: Nemlig kortproduktion og ruteberegninger.

Det her afslører jo blot, at kort i forskellige skalaer har forskellige formål. Insisterer man på at lave noget til én skala, kan det være tæt på ubrugeligt til andre formål. OSM bevæger sig på mange forskellige niveauer, hvis man zoomer ind på forskellige områder. Pga. den lidt anarkistiske struktur som hele projektet har. 

Er nogen bekendt med ruteberegnere, som kan inkludere arbitrært udformede pladser (konkave og konvekse) i deres beregninger? Jeg sad og nørklede lidt med det igår og kan godt se, hvordan jeg potentielt kan inkludere det i min software, men helt generelt passer flader dårligt til behovet for en graf til ruteberegninger.

Hilsen
Uffe

Michael Hammel wrote: 

Princippet er at du ikke tegner til en given rendering i en editor eller en anden arbitrær repræsentation, men kortlægger som tingene er i det fysiske. 
 
Veje bygges udfra vejmidter og repræsenteres med en bredde som passer til signaturen på dens størrelse og type. (uanset antal vejbaner, cykelbaner og fortove, og andre relationer som tilføjes signaturen).
 
Du kan faktisk tale med dine GIS-folk om de registerer pladser, og om ikke pladsen måles til omkransende husenes yderkant og vejes midter, eller om det er den inderste side af vejes fortove som måles. 
 
Hvis pladsen skal have funktion i routingen, og ikke blot være en grafisk illustration, skal den have kontakt til det omliggende netværk.
 
http://wiki.openstreetmap.org/wiki/Key:area
 
/m
 
Med venlig hilsen
 
Michael Hammel
 
M. +45 40 70 83 70
 
 
 
 


________________________________



 
_______________________________________________
Talk-dk mailing list
Talk-dk at openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-dk
  
-------------- næste del --------------
En HTML-vedhæftning blev fjernet...
URL: <http://lists.openstreetmap.org/pipermail/talk-dk/attachments/20120213/3e6d93ce/attachment.html>