[Seite 1]
Leistungsbeschreibung
„Software für einen Digitalen Zwilling
zur Georeferenzierung historischer
Bilddaten“
- ALLGEMEINE PROJEKTBESCHREIBUNG
Die Stadt Hildesheim konnte im Jahr 2021 Teil des durch das Bundeministerium für Inneres, Heimat und Sicherheit aufgelegten Förderprogramms „Modellprojekte Smart Cities“ werden. Bis Ende 2027 soll die Stadt Hildesheim modellhafte Lösungen auf dem Weg der digitalen Transformation hin zu einer Smart City entwickeln. Für die seit 2022 laufende Umsetzungsphase stehen ihr bis zum Ablauf des genannten Förderzeitraums 15 Millionen EUR Projektgelder zur Verfügung. Neben der Entwicklung modellhafter Lösungen, steht die Stadt Hildesheim vor der Herausforderung, die Digitalisierung im Sinne einer nachhaltigen und integrierten Stadtentwicklung strategisch und am Gemeinwohl ausgerichtet zu gestalten.
Mit dem Projekt "Stadt.Modell: Hildesheim in 3D" werden verschiedene Fachzwillinge von Hildesheim geschaffen. Ein digitaler Zwilling ist ein virtuelles Abbild eines physischen Objekts, Systems oder Prozesses, das in Echtzeit Daten über den aktuellen Zustand und das Verhalten des Originals sammelt und analysiert. Der digitale Fachzwillinge „Zeit.reisen“ soll dazu beitragen, die historische Entwicklung der Stadt Hildesheim nachvollziehbar zu dokumentieren und anschaulich zu vermitteln. Die räumliche Verortung historischer Bilddaten ermöglicht es, Veränderungen des Stadtbildes über die Zeit sichtbar zu machen und die Entwicklung von Straßen, Gebäuden und öffentlichen Räumen nachzuvollziehen. Auf diese Weise wird die Stadtgeschichte digital erlebbar gemacht, der Wissenstransfer unterstützt und ein weiterer thematischer Baustein des digitalen Stadtmodells geschaffen. Durch teilweise lizenziertes Material ist eine Software notwendig, die die Bildrechte des Eigentümers bewahrt und sichert.
Die Stadt Hildesheim beabsichtigt daher im Rahmen dieser Ausschreibung die Entwicklung und Bereitstellung einer entsprechenden Software für die Verarbeitung von Bilddaten zur Visualisierung im digitalen Fachzwilling „Zeit.reisen“. Ziel ist die Entwicklung einer webbasierten Anwendung zur Georeferenzierung und Visualisierung von Bilddaten.
1
[Seite 2]
- LEISTUNGSBESCHREIBUNG
Im Rahmen des Vorhabens ist eine ausschließlich webbasierte Anwendung zur Georeferenzierung von Bilddaten bereitzustellen. Die Anwendung muss mindestens die folgenden Anforderungen erfüllen:
Bereitstellung einer webbasierten Anwendung zur Darstellung der georeferenzierten Bilddaten • Bereitstellung einer webbasierten Softwarelösung mit eigenständigem Frontend und Backend. Eine Installation als Desktopanwendung oder mobile App ist nicht zulässig. • Die Anwendung muss mindestens in deutscher und englischer Sprache verfügbar sein. • Im Frontend müssen georeferenzierte Bilddaten auf einer interaktiven Übersichtskarte als klickbare Punkte dargestellt werden können. • Die Übersichtskarte soll den Aufnahmestandort innerhalb des historischen Bildes darstellen, z.B. mit einem Mouse-over des Punktes und einer entsprechend markierten Fläche. • Die Anwendung muss eine Suchfunktion bereitstellen, mit der gezielt nach Straßen, Adressen, Orten oder sonstigen geographischen Objekten in der Übersichtskarte gesucht werden kann. • Die Ansicht der Einzelbilder muss die üblichen Navigationsfunktionen (Zoomen, Verschieben, Vollbildansicht) einer Kartenanwendung unterstützen. • Die Ansicht der Einzelbilder kann angepasst werden, min. Ausblenden des historischen Bilds sowie Einstellen von Transparenz und Bildtiefe. • Zu jedem veröffentlichten Bild müssen mindestens folgende Metadaten sichtbar sein: o Titel (sofern vorhanden), o Aufnahmejahr bzw. Zeitraum, o Quellenangabe bzw. Rechteinhaber:in, o optionale Beschreibung. • Für jedes veröffentlichte Bild muss eine dauerhaft erreichbare URL erzeugt werden können. Zusätzlich muss eine Teilen-Funktion (Share-Funktion) zur Verfügung stehen. • Die Übersichtskarte soll eine Filterfunktion der Bilder nach Zeitraum und Stichworten, ermöglichen. • Die Darstellung muss sowohl auf Desktop als auch auf mobilen Endgeräten über aktuelle Webbrowser nutzbar sein (Responsive Design).
Administrationsbereich und Georeferenzierung • Der Administrationsbereich darf ausschließlich authentifizierten Nutzer:innen zugänglich sein. Die Authentifizierung soll über das bereits eingesetzte IDM Keycloak im Kubernetes Cluster stattfinden. • Administrator:innen müssen historische Bilddateien und Sammlungen in gängigen Bildformaten (mindestens JPEG und TIFF) hochladen können. • Beim Hochladen müssen Metadaten mindestens zu folgenden Informationen erfasst und bearbeitet werden können: o Titel, o Beschreibung, o Aufnahmejahr bzw. Zeitraum, o Quelle bzw. Rechteinhaber:in,
2
[Seite 3]
o Urheber:in (soweit vorhanden), • Die Anwendung im Backend muss eine interaktive Georeferenzierung der Bilddaten ermöglichen, hierfür müssen mindestens folgende Funktionen bereitgestellt werden: o Festlegung des Kamerastandortes, o Ausrichtung der Blickrichtung, o Anpassung des Blickwinkels, o Veränderung von Neigung und Zoom zur möglichst genauen räumlichen Zuordnung. • Während der Georeferenzierung muss das historische Bild synchron mit einer aktuellen Karten- oder Luftbildgrundlage dargestellt werden. • Änderungen an Georeferenzierungen und Metadaten müssen nachträglich bearbeitet werden können. • Administrator:innen müssen Bilder veröffentlichen, ausblenden oder vollständig entfernen können. Ebenfalls ist ein Bearbeitungsstatus zu verwalten (Entwurf, Veröffentlicht, etc.) • Nicht veröffentlichte Bilder dürfen ausschließlich im Administrationsbereich sichtbar sein. Das Veröffentlichen der Bilder darf die dahinter liegenden Bildrechte nicht beeinflussen. Die festgelegte Lizenz/Rechteinhaber:in muss bei der Veröffentlichung kenntlich sein.
Datenhaltung, Schnittstellen und Systemanforderungen • Sämtliche Bilddaten und Metadaten müssen in einer strukturierten Datenbank gespeichert werden. • Die Anwendung soll auf einem Kubernetes Cluster betrieben werden und muss deploymentfähig geliefert werden. • Eine Dokumentation für Installation, Administration und Betrieb ist in Deutsch oder Englisch als digitale Dokumentation bereitzustellen. . • Die Anwendung muss den aktuellen Anforderungen an Datenschutz und IT-Sicherheit entsprechen. • Der öffentliche Zugriff auf Bilddaten darf ausschließlich auf freigegebene Inhalte erfolgen, nicht veröffentlichte Bilder sowie interne Verwaltungsdaten dürfen öffentlich nicht zugänglich sein.
- WEITERE ANFORDERUNGEN:
Zur Abstimmung wird eine anlassbezogene und kontinuierliche Abstimmung je nach Fragestellung per E-Mail, Telefon oder Videokonferenz in deutscher Sprache durchgeführt.
Das Deployment im Kubernetes Cluster soll aus einer eigenen Datenbank, einem Backend und dem Frontend bestehen. Folgende Dienste werden von der Auftraggeberin bereitgestellt: • IIIF-Server zur Bereitstellung der Bilder und Metadaten über eine standardisierte API an den Digitalen Zwilling • Grundlegende Geodaten für die Kartendarstellungen • Keycloak als einzusetzendes Identitätsmanagement
Wünschenswerte Funktionen:
3
[Seite 4]
• Im öffentlichen Bereich können Bilder mit offener Lizenz von Usern georeferenziert werden. Diese Bilder sind strikt von Bildern mit geschlossener Lizenz zu trennen – Diese sind nur im authentifizierten Bereich zugänglich und verarbeitbar. • Beobachtungen/Kommentare können an veröffentlichten Bildern ohne Login getätigt werden können. Diese Texte bedürfen einer Freigabe im Backend. • Lieferung des Frontends im Corportate Design der Auftraggeberin.
Die Durchführung und das Ergebnis der ausgeschriebenen Leistung ist zwingend an den Vorgaben der Fördermittelgeber (Smart City Förderung) auszurichten. Dies beinhaltend unter anderem die Notwendigkeit, Software Open Source zu entwickeln, bzw. vorhandene Software bereits auf gängigen Plattformen veröffentlicht ist. Eingesetzte Software muss über offene Schnittstellen verfügen. Die gelieferte Software muss vollständig auf einem von der Stadt Hildesheim bereitgestellten Repository dokumentiert und hochgeladen werden.
Die Auftraggeberin sieht den Leistungsbeginn unmittelbar nach Zuschlagserteilung in diesem Verfahren vor. Die Auftraggeberin beabsichtigt die schnellstmögliche Zuschlagserteilung spätestens bis Ende Oktober.
- ZUSCHLAGSKRITERIEN
Für die Zuschlagsentscheidung werden die Angebote anhand der nachstehend beschriebenen Zuschlagskriterien und dem beschriebenen Wertungsschema bewertet:
- Preis Gewichtung: 30%
Der von den Bietenden angebotene Brutto-Preis wird in eine Punkteskala von 0-10 Punkten umgerechnet.
• 10 Punkte erhält das nicht auszuschließende Angebot mit dem niedrigsten Wertungspreis. • 0 Punkte erhält ein fiktives Angebot mit dem 2-fachen des niedrigsten Wertungspreises. Alle wertbaren Angebote mit darüber liegenden Bewertungspreisen erhalten ebenfalls 0 Punkte. • Die Punkteermittlung für die dazwischenliegenden Bewertungspreise erfolgt über eine lineare Interpolation. Bei der so errechneten Punktzahl findet nur die erste Nachkommastelle Berücksichtigung. Alle weiteren Nachkommastellen fallen ohne Auf- oder Abrundung weg.
Die so erreichte Punktzahl wird mit dem Gewichtungsfaktor 30 multipliziert. In diesem Kriterium sind daher maximal 300 Punkte zu erreichen.
- Mock-Up Konzept Gewichtung: 70%
4
[Seite 5]
Das von den Bietenden eingereichte Konzept/Mock-up der Software wird auf Erfüllung der Anforderungen, zusätzlichen Features, Benutzerfreundlichkeit, Design und Anpassungsfähigkeit qualitativ bewertet. Das einzureichende Konzept/Mock-up ist auf maximal 10 Bildschirmansichten bzw. 15 DIN-A4-Seiten begrenzt. Eine Programmierung oder klickbare Umsetzung wird nicht erwartet.
| Das Kriterium wird anhand einer Skala von 0-10 Punkten bewertet. Die erreichte Punktzahl wird | |||
|---|---|---|---|
| mit dem Gewichtungsfaktor 70 multipliziert, sodass maximal 700 Punkten vergeben werden | |||
| können. Die Punktevergabe erfolgt nach folgender Abstufung, welche den Erfüllungsgrad des | |||
| Erwartungshorizonts bemisst. | |||
| • Überdurchschnittlich gute Erfüllung 8-10 Punkte | |||
| Das eingereichte Konzept entspricht vollständig der ausgeschriebenen Leistung. Das | |||
| Konzept verfügt über ein ansprechendes UI-Design, bietet zusätzliche bedeutende, | |||
| nicht explizit geforderte sinnvolle Funktionen, zeichnet sich durch hervorragende | |||
| Anpassungsmöglichkeiten aus und wirkt äußerst benutzerfreundlich. | |||
| • Durchschnittliche Erfüllung 5-7 Punkte | |||
| Das eingereichte Konzept entspricht den wesentlichen Anforderungen der | |||
| ausgeschriebenen Leistung. Das UI-Design ist zweckmäßig und übersichtlich. Die | |||
| geforderten Funktionen sind vorhanden und nachvollziehbar dargestellt. Weitere | |||
| Funktionen von nicht zentraler Bedeutung sind vorhanden. Anpassungsmöglichkeiten | |||
| sowie Benutzerfreundlichkeit entsprechen dem üblichen Standard. | |||
| • Unterdurchschnittliche Erfüllung 2-4 Punkte | |||
| Das eingereichte Konzept erfüllt die Mindestanforderungen der ausgeschriebenen | |||
| Leistung. Wesentliche Funktionen sind nicht oder nur unzureichend dargestellt. Das UI- | |||
| Design wirkt wenig überzeugend, die Anpassungsmöglichkeiten sind eingeschränkt und | |||
| die Benutzerfreundlichkeit weist erkennbare Schwächen auf. | |||
| • Keine Erfüllung 0-1 Punkte | |||
| Das eingereichte Konzept erfüllt die Anforderungen der ausgeschriebenen Leistung | |||
| nicht oder nur in vernachlässigbarem Umfang. Wesentliche Funktionen fehlen, die | |||
| Darstellung ist nicht nachvollziehbar und das Konzept lässt keine ausreichende Eignung | |||
| zur Erfüllung der ausgeschriebenen Leistung erkennen. | |||
| Wird ein Angebot mit der Bewertungsstufe „Keine Erfüllung“ bewertet, wird das Angebot | |||
| mangels Erwartung einer vertragskonformen Leistungserbringung vom Vergabeverfahren | |||
| ausgeschlossen. |
a usgeschlossen.
5