Jeg har brug for et spark i den rigtig retning til at forstår hvordan jeg skal brug relations. Lige nu vil jeg gerne sorger for at de hytter og andre bygninger og grunde jeg redigere for Det Danske Spejderkorps har den rigtig relation til korpset.
Såååå, hvad skal jeg læs for at forstår det?
Jeg forventer at DDS (Det Danske Spejderkorps) har et ID af en slags som jeg kan tildele til relevante features så de har en relation til hinanden og en anden vil kunne for svar på “giv mig en liste af alle shelter drevet af DDS med drikkevand”.
Jeg forstår bestemt heller ikke alle aspekter af relationer i OSM, men jeg tror umiddelbart ikke de skal bruges på den måde du skitserer. Umiddelbart vil jeg tro, at ‘Operator’ er mere passende?
Jeg ville også vælge operator=Det Danske Spejderkorps taget på de objekter (bygninger, shelters, bålpladser osv) som korpset ejer/bestyrer. Jeg ville ikke bruge operator=DDS forkortelsen, den strider også imod OSM politik om at man skal helst undgå akronymer.
Hvis I skal bruge en unik-id nøgle for Det Danske Spejderkorps så findes der wikidataelementet Q12308331 - det har den fordel at den samler mange sprog (hvad korpset hedder på forskellige sprog) i et hug så i OSM tilføjes dette tag
operator:wikidata=Q12308331
Så for at gøre det helt perfekt så brug de to ovenstående tags.
NB hvis en spejderhytte har et navn fx via et skilt på hytten, så tilføj gerne dette navn i name=HYTTENAVN taget i OSM.
Kommentar? Forslag? Hvis vi i denne tråd er enig om at det ser godt ud vil jeg starte en ny tråd som et forslag til hvordan spejder hytter/shelter osv registreres i Danmark.
Jeg går ud fra at det er alle hytter, shelters, bålpladser mm Det Danske Spejderkorps driver du vil knytte sammen i denne relation? Det er ikke hensigten med denne relation type at knytte meget langt fra hinanden geografiske objekter sammen på denne måde.
I stedet for brug operator= NN eller lign. og så søges efter dette tags og du finder alt (såfremt det er blevet kortlagt og angive) der drives af DDS. Der er et godt eksempel fra Wiki-siden. Hvor det ikke anbefales type=site at bruge denne relation.
" Each location of a fast food chain is a fast food restaurant in its own right, so it should stand alone as an amenity=fast_food feature without a relation. Use matching values of name=* , operator=* , owner=* , or brand=* to establish that the restaurants in the chain are somehow related."
Det Danske Spejderkorps (DDS) er det nationale organisation. Det jeg fokusere på lige nu er en såkaldt ‘gruppe’ som er medlem af DDS. En gruppe er den lokal aktiv enhed med børn som medlemmer og et mødested, måske også bålplads, shelter osv. Så jeg mener det er gruppen som er “directly in charge of the current operation”.
Så det er ikke min hensigt at laver relations mellem DDS og kortobjekter tilknyttet lokale gruppe.
Det er for mig stadig et åbent spørgmål om/hvordan jeg kan lave en forbindelse mellem den enkelte gruppe og den nationale organisation. brand=* er det eneste jeg har fundet der virker nogenlunde relevant.
relation mellem den lokale spejdergruppe og dennes adresse
relation mellem den lokale spejdergruppe og deres anlæg
dog ikke hvor selve grunden med deres anlæg har en relation til gruppen
Ad. 2 er jeg lidt usikker på den bedste vej frem.
Da der er helt 5 spejderkorps i Danmark vil jeg gerne finde en god måde at vis relation mellem gruppen og det korps de er medlem af. Det er ikke altid det fremgår af deres navn. Jeg har prøvede at finde noget på How to map a men kan ikke se eksempler på at man kan vis et tilhørsforhold/medlemskab. For nu er det håndteret som:
name=Skanderborg Gruppe, Det Danske Spejderkorps
operator=Skanderborg Gruppe
Er der i øvrigt et shelter (offentlig tilgængeligt?) nede ved vandet? Det ligner det på luftfoto.
Der ned ved vandet med relation til gruppen er kun et brændeskur.
Det lyder som om, at du stadig tænkt dig at bruge en relation til at samle den lokale gruppes ting (hytte, shelters, bålsted etc.)? Ud fra det du skriver, kan jeg dog stadig ikke se, hvorfor ‘operator’ ikke er den bedste løsning til det.
Medmindre altså du gerne vil reservere ‘operator’ til DDS. I så fald ved jeg heller ikke lige, hvordan man tagger et “underniveau” til dette, men udover ‘brand’ kunne det måske være ‘branch’?
Hvad ville du gøre de steder som fx. her i Ishøj, hvor DDS og KFUM deler en hytte ejet af kommunen? (Eller det gjorde de i hvert fald indtil for en måned siden hvor den desværre brændte ned.)
Hvis to funktioner deler en bygning mener jeg at ideen er hver dunktion oprettes som node (dvs seperat fra bygningen) og en relation oprettes til bygningen. Fra det jeg har læst er det bedre hvis bygningens areal kam deles, men det kan ikke altid gøres retvisende.
Helt præcis hvordan man knytter to funktioner med hver deres adresse til samme bygning ved jeg ikke. @circinate prøver at finde ud af det for Thorolf - Spejderne på Islandsbrygge, Artillerivej 67b. De deler bygning med en børnehave og deres udearealer er på en kommunalt grund.
Jeg er enig med @Lostmonkey ang. brug af ‘operator’. Så jeg har skrevet det ind på de nodes som er forbundet af en ‘site’ relation. Men jeg mangler en tolkning af hvordan man burde brug ‘site’ relation hvor det ville være forkerte at de er med i én samlet relation. Lade os sige at gruppen har en lejrhytte et helt andet sted (det vide jeg ikke om de har) så kan jeg godt se at den lejrhytte ikke skulle være med i en ‘site’ relation. Men de der flagstang, brændeskur og bålplads er i nær fysisk relation til selve spejderhytten, uden at de er med på en grund som gruppen er ‘operator’ for (jeg kan se at grunden er drevet vist af en ‘Vestermølle’ forening eller lign.)
vis de ting var på samme grund hvor spejdergrupen var ‘operator’ var der ingen grund til at gøre mere. Det kunne ses ud fra placering af deres operator må være spejdergruppen.
vis de ting ligger udenfor en grund drevet af spejdergruppen skal de bindes sammen på en måde. En fælles ‘operator’ giver god mening (@Duncan_Lithgow siger at det er deres og de passer dem)
at de er en aktiv del af spejdergruppens aktiviteter kræver (synes jeg) en anden registrering … @Duncan_Lithgow har prøvede en ‘site’ relation, måske er det forkerte.
Jeg kan ingen sted finde løsninger på lign situationer - selvom der må være rigtig mange derude.
fra wikien:
A site relation is used to group several objects which have a single identity as a whole, but cannot be accurately described by other data types. Like a multipolygon relation, a site allows representation of a single discontiguous geometry, as opposed to an organizational relationship or a spatial relationship that is merely a coincidence.
På denne fremmede grund er der flere elementer som samlet danne en spejdergruppe. De er af forskellige types (node/landskab/polygon) … men kan de samles af en anden data type?
At samle dem med et eller andet vil også undgå redundans af data. Vi kunne også undgå at de alle skal have en ‘operator’ da det ville være implicit i deres relation til spejdergruppen.
Hvad angå deres medlemskab af Det Danske Spejderkorps synes jeg ‘brand’ er den oplagt løsning (som @Lostmonkey næsten foreslå) efter jeg læser siden på wiki. Det lyder måske mærkelig på dansk (brand=mærke) men passer bedst.
Beklager jeg har skrevet så meget, jeg håber vi snart kan finde nogle andre spejdergruppe at prøve en standard på.
Jeg har valgt at give både spejdergruppen og børnehaven på Artillerivej en relation til deres respektiv adresse. Deres relation til bygningen synes jeg ikke er så vigtigt i første omgang, det er ret tydelig ud fra placering af adresse node på kortet at det er den bygning det handler om.