Visning av enkeltminner for en lokasjon #132
Comments
|
La meg se om jeg har forstått dette riktig.
|
Så lenge begge er polygoner og de er organisert sånn noen lunde som i eksempelet over, så er det en ting. Men jeg tror at det også kan være tilfeller der det bare finnes punktinformasjon. Hvis en også skal håndtere dette - hva er realistiske alternativen da? |
|
Dette ser veldig, veldig lovende ut. Såpass detaljerte områdedata gir jo visningen en ny dimensjon. For å rydde litt sånn rent visuelt - kunne det vært en ide å fjerne punktmarkører nå polygon vises? |
|
Og da må kanskje valgt polygon - enkeltminne eller lokasjon - få en eller annen visuell markering? Når en mister fargeendringer på punktmarkøren? |
|
@havardgj det er en tanke! Med "når polygon vises", tenker du da lokalitetspolygon eller enkeltminne-polygoner? |
|
Lokalitetspolygon i utgangspunktet. Og logikken må vel da knyttes til om polygon faktisk finnes. Det samme gjelder vel i prinsippet for enkeltminner, der det i teorien også kan væe enkeltminner som ikke har polygoner. Det kan være et praktisk problem at lokasjonspolygonene som dukker opp i noen få tilfeller kan være veldig små og derfor vanskelige se rett og slett - det har vært snakk om at f.eks. en flaggstang finnes som polygon, men hypotesen er at dette er et mindre problem som en evt. .må håndtere senere. |
|
Jeg har prøvd noen timer nå på å få til dette med å skjule markører når polygon vises. Det viste seg å ikke være så lett, mest på grunn av at vi også bruker clustring på markører, og markercluster-pluginen skaper en del problemer. Jeg har dermed gitt opp dette for nå, men noe fikk jeg gjort: koden for å håndtere enkeltminner og polygoner for lokasjoner har blitt ryddet opp og lettere å forstå. Du får ta en avveiing på om jeg skal bruke mer tid på dette med å skjule polygoner. Et problem med å skule markører sånn rent praktisk er også at noen polygoner ligger helt under andre, og blir dermed ikke klikkbare. En annnen ide er jo å gjøre med lokasjonspolygoner som med enkeltminner: kun vise dem ved klikk. Da unngår vi å ha mye overlappende data. |
|
Her er en spørring som gjør det mulig å hente ut polygoner for flere lokasjoner i en spørring: select ?lok ?poly where { Forhåpentligvis kan denne effektivisere eksisterende løsning og kanskje også gjøre det mulig å hente alle polygoner for alle lokasjoner på laveste zoomnivå - selv om det i noen tilfeller kan være mer enn grensen på 10 som er brukt i eksisterende logikk. |
|
Hovedproblemet med punkter og polygoner er at det er vanskelig å forstå hvilke polygoner som hører til hvilke punkt. Og et annet sentralt problemet er som du sier at noen polygoner ikke er klikkbare ettersom de ligger bak andre polygon. Samtidig ser det ut til at punktmarkørene på en måte løser det andre problemet - de er alltid klikkbare og så vidt jeg forstår så gjør de det da praktisk mulig å nå alle lokasjoner - selv om ikke alle polygoner kan klikkes på. Vil det da være en løsning å se litt er på det visuelle i den løsningen du har nå? Hvis en kan markere både polygoner og punkt så blir det mulig å se sammenhengen mellom den. Og da skal det være mer forståelig å bruke punktene for valg av polygoner.
|
|
Da har jen en første versjon av dette på plass Se Jeg har måttet gjøre om litt på clustringa: under zoomnivå 13 clustres ikke riksantikvaren-laget Det gjenstår også noen ting
Spørringen for å hente polygoner for en rekke lokasjoner var "god-sent" her! Tar gjerne imot feedback her |
|
Synes dette begynner å fungere bra - basert på forutsetningene. Og selv om det kanskje er tekniske grunner til å fjerne clustering på noen nivå, så er det jo også med på å redusere den visuelle kompleksiteten - en type innhold mindre å forholde seg til. Rent visuelt så blir en del av gruppene med punktmarkører veldig kompakte og det kan være litt vanskelig å se/forstå hva som er de enkelte markørene. Er det mulig å sette en viss gjennomsiktighet på disse markørene - når det ikke clustres? Et annet spørsmål er hvordan dette i praksis fungerer med bilder for noen av lokalitetene - ref #135? Her jobber jeg med å få tilpasset spørringen slik at en kun får ett objekt for hver lokasjon - selv om det finnes flere bilder. Ser at det i alle fall fort blir forvirrende om en får flere lokalitetspunkt for en lokalitet, så kanskje greit å vente med å teste dette til denne spørringen er på plass? |
|
Ser nå at dette er satt opp og fungerer med bilder - det var bare ingen bilder i dette området. Så da kan dette med bilder og justering av spørring heller håndteres i #135. |
|
Har testet logikken litt rundt Oscarsborg, for å sjekke med det som ser ut til å være et av de vanskeligste casene. Som du ser i denne filmen så er det et par litt uheldige ting som det kanskje er mulig å se på?
Litt usikker på hva som er løsningen og hvor mye logikk man bør legge inn for det som vel strengt tatt burde vært en geografisk spørring mot datasettet av typen gi meg alle lokaliteter som har punkt, hele eller deler av området innenfor denne boksen. Men hadde det vært mulig å beholde lokalitetspolygoner som er vist - sammen med enkeltminnepolygonene som vises nå - f.eks. helt til man zoomer ut til nivået der clustering aktiveres igjen? https://www.dropbox.com/s/2qgqsaxv4gf5n72/Screen%20Recorded2015-11-30%2012_35_34.mov?dl=0 |
|
Denne issuen var ikke enkel. Har knøla rundt med mye nå, men fikk tilslutt fikset feilene du oppdaget. Jeg synes løsningen er relativt treg, men det skal ihvertfall fungere. Fint om du kan re-teste @havardgj |
|
Synes det interaksjonsmessig fungerer mye bedre nå. Men ser også at det kanskje virker litt treigt. Har du noen ide om hvor dette ligger? Er det datamengde, bearbeiding av data eller rendring på en eller annen måte? Rent visuelt så er det eneste jeg lurer på muligheten for å sette en gjennomsiktighet for punktmarkørene for å gi et litt riktigere bildet av innholdet ved overlappende markører. Var det mulig? |
|
Når logikken for visninger av polygoner nå er litt mer forutsigbar - vil det da hjelpe noe å sette ned igjen grensen for antallet punkter før polygoner skal vises? |
|
Bra! Jeg skrev om ganske mye, slik at nå hentes polygoner for alle punkter synlige i (og 20% utenfor) kartet. Dette gjør at det blir ganske mye lasting av data (polygoner på hver zoom/pan). Jeg mistenker tregheten skyldes dette, pluss at vi nå ikke clustrer når man er zooma inn. Dette medfører mange punkter i kartet. Nå har vi jo en spørring for alle polygoner, så logikken med antall punkter er fjernet, jeg går kun på zoomnivå. Tror nok det kan være en ide å gjen-innføre antall punkter for å få ting til å gå litt raskere. Skal teste litt mer! |
|
Da har jeg gjort en sjau her! Det var som sagt mye rart, men nå har jeg skrevet om slik at den "unclustrer" og viser polygoner når det er mindre enn X (der x by default er 20) "features" i kartet. Dette gjorde ting mye raskere, og jeg klarer ikke å se at jeg har "ødelagt" annen funksjonalitet heller. Kan testes på divshot, men om du ikke finner noe veldig graverende har jeg lyst til å parkere denne nå. (cc @havardgj ) |
|
Litt usikker på hva som ble siste versjon her. Er det nå en kombinasjon av zoom-nivå og antall punkt? Eller gikk du tilbake til kun antall "features"? |
|
For å kompensere litt for de manglende geospørringene hadde det vært interessant å se om det var mulig å prøve å justere innslagspunktet for visning av polygoner - enten ved å øke antall fra 20 til f.eks. 40 eller sette visningen for ett zoomnivå høyrer - avhengig av hva som er mulig og hva som er best med den logikken som er der nå. |
|
Pr nå er det basert på zoomnivå, siden vi nå kan hente en rekke polygoner i samme spørring er det ikke noe problem med antall mer |
|
Så vidt jeg kan se vises polygoner nå på zoomnivå 16. Hadde det da vært mulig å teste om det fungerer å vise dem allerede på nivå 16? |
Ved visning av polygone(er) for lokasjon - også vise polygoner for enkeltminner for samme lokasjon.
Ved klikk på polygon - gå til detaljvisning for enkeltminne med navn, beskrivelser og kategori (enkcatlabel)
Spørring for å hente enkeltminner for en lokasjon:
SELECT ?enk ?name ?desc ?area ?enkcatlabel
where {
?enk a https://data.kulturminne.no/askeladden/schema/Enkeltminne .
?enk rdfs:label ?name .
?enk https://data.kulturminne.no/askeladden/schema/i-lokalitet https://data.kulturminne.no/askeladden/lokalitet/173268 .
?enk https://data.kulturminne.no/askeladden/schema/beskrivelse ?desc .
?enk https://data.kulturminne.no/askeladden/schema/geo/area/etrs89 ?area .
?enk https://data.kulturminne.no/askeladden/schema/enkeltminnekategori ?enkcat .
?enkcat rdfs:label ?enkcatlabel .
}
https://sparql.kulturminne.no/?default-graph-uri=&query=SELECT+%3Fenk+%3Fname+%3Fdesc+%3Farea+%3Fenkcatlabel%0D%0Awhere+%7B%0D%0A%3Fenk+a+%3Chttps%3A%2F%2Fdata.kulturminne.no%2Faskeladden%2Fschema%2FEnkeltminne%3E+.%0D%0A%3Fenk+rdfs%3Alabel+%3Fname+.%0D%0A%3Fenk+%3Chttps%3A%2F%2Fdata.kulturminne.no%2Faskeladden%2Fschema%2Fi-lokalitet%3E+%3Chttps%3A%2F%2Fdata.kulturminne.no%2Faskeladden%2Flokalitet%2F173268%3E+.%0D%0A%3Fenk+%3Chttps%3A%2F%2Fdata.kulturminne.no%2Faskeladden%2Fschema%2Fbeskrivelse%3E+%3Fdesc+.%0D%0A%3Fenk+%3Chttps%3A%2F%2Fdata.kulturminne.no%2Faskeladden%2Fschema%2Fgeo%2Farea%2Fetrs89%3E+%3Farea+.%0D%0A%3Fenk+%3Chttps%3A%2F%2Fdata.kulturminne.no%2Faskeladden%2Fschema%2Fenkeltminnekategori%3E+%3Fenkcat+.%0D%0A%3Fenkcat+rdfs%3Alabel+%3Fenkcatlabel+.%0D%0A%7D&format=application%2Fsparql-results%2Bjson&timeout=0&debug=on
The text was updated successfully, but these errors were encountered: