Zakup i wdrożenie oprogramowania GIS. - polska-tarnów: przemysłowe specyficzne pakiety oprogramowania

Zamiast: 

II.1.5) Krótki opis zamówienia lub zakupu:

I. Szczegółowy opis przedmiotu zamówienia:

1. Podstawowe założenia architekturalno – funkcjonalne

1. System ma zapewnić uproszczenie i optymalizację:

a) ewidencji infrastruktury sieciowej,

b) rejestracji i obsługi procesu wydawania warunków technicznych, uzgodnień terenowych i obsługi służebności,

c) analiz,

2. System ma być oparty na otwartej i rozwojowej architekturze – także dla Zamawiającego. Oznacza to, że konfiguracja systemu powinna być modyfikowalna przez Zamawiającego za pomocą intuicyjnych graficznych narzędzi oraz narzędzi programistycznych.

3. System ma być budowany zgodnie z założeniami OpenGIS i OGC (Open Geospatial Consortium) oraz dyrektywą unijną INSPIRE.

4. Program musi być zbudowany w architekturze trójwarstwowej opartej na serwerze danych przestrzennych, serwerze aplikacyjnym i „cienkim” kliencie. Wyjątkiem mogą być stanowiska edycyjne (desktop), które mogą być oparte o „grubego klienta”.

5. Program i narzędzia administracyjne systemu muszą pozwalać na zdalną administrację systemem i muszą umożliwiać samodzielny rozwój systemu: między innymi dodawanie nowych pól, słowników, elementów graficznych, dodawanie nowych tabel, definiowanie pól wyliczalnych, budowanie relacji między tabelami – wszystko bez konieczności programowania,

z wykorzystaniem narzędzi wizualnych.

6. System ma być zbudowany w architekturze, której otwartość pozwoli integrować się

w oparciu o powszechnie stosowane mechanizmy wymiany danych.

7. System ma zapewnić mechanizm, dzięki któremu nie będzie trzeba indywidualnie konfigurować oprogramowania na każdej stacji roboczej użytkownika, ale będzie możliwe centralne tworzenie konfiguracji dla poszczególnych użytkowników, grupy użytkowników lub dla wszystkich.

8. System ma umożliwiać wykonywanie zapytań (analiz, raportów) poprzez ogólne mechanizmy bazodanowe (co najmniej SQL) w oparciu o intuicyjny interfejs graficzny.

9. System musi mieć możliwość tworzenia aplikacji GIS w wersji off-line z aktualnymi danymi dla użytkowników pracujących w terenie bez konieczności dostępu do wersji on-line. System musi posiadać mechanizm synchronizacji danych z wersji off-line z danymi z wersji on-line oraz w drugim kierunku.

10. System musi zapewniać bezpieczny dostęp on-line do aplikacji poprzez sieć Internet

z wykorzystaniem przeglądarki internetowej.

11. System musi integrować się z posiadanymi przez Zamawiającego aplikacjami: ERP (środki trwałe), oprogramowaniem do obliczeń hydraulicznych (TERMIS).

12. System musi umożliwiać definiowane miejsca przechowywania załączników (grafika, wideo, inne) w zależności od ich rodzaju i rozmiaru, albo w bazie danych albo poza nią.

2. Opis ogólny systemu

1. System ma obsługiwać w jednolity sposób zarówno dane opisowe jak i geometryczne ewidencjonowanych elementów sieci ciepłowniczej wraz z prezentacją na tle podkładów (rastrowych, wektorowych i rastrowo-wektorowych) oraz obsługiwać ich przejścia w obie strony (uzyskiwanie grafiki od strony opisu i na odwrót).

2. System dzięki integracji z innymi aplikacjami, ma stanowić jeden z elementów systemu informatycznego przedsiębiorstwa.

3. System ma przechowywać dane w jednej centralnej bazie systemu – Oracle 12c Standard Edition One z licencją na 1 procesor lub równoważnej spełniającej wszystkie cechy w/w bazy danych.

4. System ma zapewnić ewidencję oraz edycję danych opisowych i geometrycznych dotyczących sieci ciepłowniczej oraz innej infrastruktury w postaci warstw zgodnie

z instrukcją K1, G7.

5. System ma wspierać procesy związane z wydawaniem warunków technicznych, uzgodnień terenowych i obsługą służebności.

6. System ma odzwierciedlać zależności topologiczne pomiędzy obiektami infrastruktury ciepłowniczej i zapewniać dużą elastyczność i wierność w modelowaniu istniejących

i projektowaniu nowych obiektów.

3. Platforma systemowa

1. Moduły systemu GIS muszą stanowić jednolite i spójne środowisko systemowe, umożliwiające wykonanie pełnej funkcjonalności w ramach tego środowiska.

2. Protokół komunikacyjny TCP/IP.

3. W przypadku zerwania połączenia sieciowego między serwerem bazy danych,

a aplikacją musi być ono wykrywane i następować ma próba jego automatycznego odtworzenia.

4. System musi umożliwiać tworzenie kopii bezpieczeństwa zarówno w trybie off-line na wyłączonej bazie danych jak i w trybie on-line na pracującej bazie danych.

4. Architektura systemu

1. Architektura modułowa umożliwiająca łatwy i etapowy rozwój systemu.

2. System ma być zbudowany w technologii trójwarstwowej (klient – serwer aplikacji – serwer bazy danych).

3. Architektura całego systemu ma być otwarta (OpenGIS) i zgodna z założeniami OGC (Open Geospatial Consortium).

5. Infrastruktura informatyczna

5.1. Zamawiający oczekuje od Wykonawcy dostarczenia:

5.1.1. Dokumentacji architektury technicznej systemu uwzględniającej wszystkie elementy niezbędne do zapewnienia prawidłowego działania systemu.

5.1.2. Dokumentacji bazy danych, która powinna zawierać specyfikację konfiguracji bazy danych z informacjami o schematach bazy danych, na których są przechowywane dane aplikacji; informacje o przestrzeniach tabel, informacje o istotnych obiektach aplikacji, szczególnie takich jak: linki bazy danych, procedury, pakiety i funkcje; listę kluczowych tabel aplikacji i opis zawartych w nich danych; informacje

o zalecanej konfiguracji backupu i szacowanym rozmiarze bazy danych, opis sposobu wgrywania poprawek na bazę danych, informacje, czy dostawca publikuje listę zalecanych i wspieranych poprawek dla bazy danych; diagram związków tabel używanych przez aplikację; zalecane parametry konfiguracyjne bazy danych; informacje o stronie kodowej, jaką powinna posiadać baza danych; informacje

w jaki sposób powinna być uruchamiana i zatrzymywana aplikacja i baza danych.

5.1.3. Dokumentacji instalacji i konfiguracji dla wszystkich składowych systemu.

5.2. Wykonawca musi zagwarantować, że zaproponowana architektura rozwiązania oraz infrastruktura informatyczna zapewnią spełnienie następujących wymagań:

5.2.1. Zapewnienie efektywnego i bezpiecznego działania systemu.

5.2.2. Zapewnienie dostępności i niezawodności systemu.

5.2.3. Zapewnienie ciągłości działania systemu.

5.2.4. Zapewnienie zabezpieczenia systemu przed przypadkowym lub celowym zniszczeniem danych lub ich modyfikacją.

5.2.5. Zapewnienie zabezpieczenia systemu przed nieuprawnionym dostępem do funkcjonalności lub danych.

5.2.6. Zabezpieczenie danych zgodnie z ustawą o ochronie danych osobowych.

5.2.7. Zapewnienie odpowiedniego środowiska testowego, szkoleniowego

i produkcyjnego.

6. Skalowalność systemu

1. System będzie zarządzał dużymi ilościami danych i zapewniał dostęp do tych danych wielu użytkownikom w tym samym czasie (wielodostęp i współbieżność).

2. System ma być skalowalny, tzn. ma istnieć możliwość rozbudowy systemu wraz ze wzrostem ilości przechowywanych danych lub liczby użytkowników, bez konieczności modyfikacji oprogramowania.

3. Baza danych systemu będzie zarządzała wszelkimi rodzajami danych występującymi w zastosowaniach typu GIS (dane alfanumeryczne, wektorowe, rastrowe, ortofotomapy, zdjęcia lotnicze, inne elektroniczne dokumenty, itp.).

4. System musi posiadać wbudowane mechanizmy wspomagające niezawodność systemu takie jak:

a) wykrywanie przerw w łączności,

b) automatyczne odtwarzanie połączenia,

c) szeroki zakres obsługi i naprawy sytuacji związanych z wystąpieniem błędu.

5. System nie może posiadać ograniczeń co do ilości stanowisk pracy w środowisku www.

W przypadku aplikacji desktop (gruby klient) zakłada się 2 jednoczesnych użytkowników.

6. System powinien być dostępny w trybie ciągłym 24 godz./dobę.

7. Baza danych i aplikacje

1. Oracle 12c Standard Edition One na 1 CPU lub równoważna + serwerowy system operacyjny. Baza danych musi obsługiwać system operacyjny Windows i Linux.

2. Centralna baza danych z możliwością wielostanowiskowego, rozproszonego dostępu (wszystkie dane w jednej centralnej bazie danych).

3. Zastosowana baza ma być zoptymalizowana pod kątem wydajności, w szczególności dla analiz przestrzennych i zarządzania informacją o sieciach. Zastosowane zmiany

w konfiguracji standardowej bazy danych w celu osiągnięcia optymalizacji muszą zostać zawarte w dokumentacji systemu.

4. System ma być oparty na ciągłej bazie geograficznej, która będzie pozwalała na traktowanie całego modelowanego obszaru jak jednej mapy oraz na prezentowanie

w jednolity sposób tak informacji przestrzennej jak i nieposiadającej odniesienia geograficznego, bez podziałów na arkusze map rastrowych czy segmentów bazy. Jest to niezwykle ważne ze względu na specyfikę przedsiębiorstwa, które zarządza sieciami, gdzie pojedynczy przewód czy kanał może przebiegać przez kilka arkuszy mapy.

5. Technika indeksowania przestrzennego ma zapewniać użytkownikom jednakowo dobrą wydajność, niezależnie od liczby równocześnie pracujących stanowisk oraz od rozmiarów bazy danych.

6. Dane mają być traktowane w taki sam sposób niezależnie od ich postaci - rastry, dane wektorowe, dane bez odniesienia przestrzennego.

8. Serwer mapowy WWW

Serwer mapowy powinien spełniać co najmniej wymienione poniżej funkcje:

możliwość publikacji usług internetowych, takich jak mapa, rastry, WMS, WCS, WFS, WFS-T, REST, i SOAP,

zawiera narzędzia do tworzenia rozbudowanych aplikacji mapowych opartych na przeglądarce internetowej,

zawiera narzędzia w postaci komponentów, które można wykorzystać w aplikacjach internetowych (przesuwanie, skalowanie, identyfikacja obiektów, pomiar odległości, wyszukiwanie adresów, zapytania i wyszukiwanie atrybutów, edycję danych wektorowych

i wydruki),

udostępnia otwarty interfejs programistyczny (Application Programming Interface – API),

obsługuje zadania podstawowej edycji danych przestrzennych, takie jak dodawanie, usuwanie i modyfikacja obiektów mapy w zakresie punktów, linii i obiektów powierzchniowych.

Zakłada się instalację serwera mapowego na dedykowanej maszynie fizycznej lub maszynie wirtualnej.

9. Język systemu

Pełna polonizacja systemu w zakresie:

raportów,

ekranów - interfejsu,

komunikatów i podpowiedzi systemowych,

dokumentacji,

obsługi polskich znaków diakrytycznych wraz z sortowaniem zgodnie z polskim alfabetem,

plików pomocy i instrukcji.

10. Bezpieczeństwo danych

1. System musi zapewniać zasadę Single Sign On, to znaczy zalogowany w systemie Windows użytkownik posiadający konto w AD, zostanie automatycznie zalogowany

w systemie GIS, jeśli będzie istniało powiązanie konta użytkownika z AD z kontem

w systemie GIS.

2. Definiowanie uprawnień do funkcji systemu dla każdego użytkownika.

3. Definiowanie uprawnień do funkcji systemu dla grupy użytkowników.

4. Definiowanie uprawnień na poziomie warstw mapy, tablic i pól tablic – poziom dostępu do danych.

5. Zapewnienie kontroli nadanych użytkownikom efektywnych praw dostępu do danych oraz funkcjonalności systemu.

6. Możliwość czasowego przyznania uprawnień.

7. Szeroka kontrola aktywności użytkowników:

a) informacja o logowaniach do systemu,

b) informacja o wprowadzanych zmianach.

11. Backup i archiwizacja danych

1. System musi zapewniać tworzenie backupu off-line i on-line.

2. Oczekiwany czas odtworzenia całego systemu z kopii zapasowej (RTO – ang. Recovery Time Objective) nie może przekroczyć 24 godzin, przy zachowaniu aktualności danych (RPO - ang. Recovery Point Objective) do 24 godzin.

3. Wykonawca dostarczy skrypty oraz dokumentację wykonywania kopii bezpieczeństwa oraz odtwarzania danych dla systemu GIS.

12. Licencjonowanie systemu

1. Zamawiający wymaga licencjonowania dla wszystkich typów stanowisk w trybie dostępu jednoczesnego, bez przypisywania licencji do użytkownika lub komputera.

2. System musi być wyposażony w mechanizm umożliwiający on-line kontrolę i zarządzanie wykorzystanymi licencjami, pozwalający na:

a) podgląd przez kogo i jaka licencja (instancja programu) jest wykorzystana oraz

z jakiego stanowiska i od której godziny,

b) wyłączenie (zabicie) sesji użytkownika,

c) konfigurację dla użytkownika maksymalnej możliwej do uruchomienia ilości instancji danej aplikacji, domyślnie 1 instancja aplikacji dla użytkownika.

3. Oferta ma uwzględniać oprogramowanie dodatkowe niezbędne dla osiągnięcia zakładanej funkcjonalności systemu GIS przy posiadanej przez Zamawiającego infrastrukturze sprzętowo – sieciowo – systemowej.

13. Posiadane dane i migracja

Zamawiający posiada następujące dane:

a) Mapy sieci cieplnej w postaci elektronicznej (pliki PDF,DWG),

b) Mapy sieci w postaci skanów,

c) Mapy sieci w postaci papierowej,

d) Dane dotyczące parametrów urządzeń sieciowych w postaci arkuszy XLS,

e) Dane dotyczące parametrów urządzeń w węzłach cieplnych w postaci arkuszy XLS,

f) Schematy technologiczne węzłów (pliki PDF,DWG),

g) Schematy lokalizacji pomieszczeń węzłów w budynkach (pliki PDF,DWG),

h) Szablony protokołów dotyczące eksploatacji infrastruktury ciepłowniczej (pliki PDF).

14. Platforma sprzętowa

Sprzęt nie stanowi przedmiotu zamówienia.

Zamawiający zapewni Środowisko wg następującej specyfikacji:

Serwer

— Procesor Intel Xeon E5-2603 v2 (2 szt.),

— 32GB RAM,

— Macierz dyskowa typu 0+1 o pojemności 2TB oparta na dyskach SAS,

— Dwie karty sieciowe 10/100/1000,

— Napęd DVD+/-RW,

— Zainstalowany system operacyjny: MS Windows Server 2012R2 64-bit PL.

Stacje robocze dla aplikacji typu „desktop”:

— Dell Vostro V3700 (i5, 8GB RAM, GeForce GT330M),

— Komputer stacjonarny (i5, 8GB RAM, GeForce GT740),

— Zainstalowany system operacyjny: MS Windows 7 Pro 64-bit PL.

15. Model danych

1. Świat w systemie ma być przedstawiany jako zestaw obiektów posiadających charakteryzujące je atrybuty, które są powiązane między sobą stosownymi relacjami.

2. Model powinien być zgodny z wymaganiami:

a) eksploatacji sieci ciepłowniczej,

b) prawa geodezyjnego (instrukcje Geodezyjne K-1 „Mapa Zasadnicza” oraz G-7 „GESUT – Geodezyjna Ewidencja Sieci Uzbrojenia Technicznego").

3. System ma umożliwiać modelowanie relacji jeden-do-jednego, jeden-do-wielu oraz wiele-do-wielu.

4. Atrybuty obiektów mogą być alfanumeryczne (znaki i liczby, jak nazwisko czy numer zlecenia) oraz graficzne (punkty, linie i obszary ze stosowną interpretacją geograficzną).

5. Każdy obiekt powinien posiadać unikalny identyfikator tworzony automatycznie przez system w postaci podanej przez Zamawiającego.

6. Podstawowym poziomem składowania danych będą obiekty takie jak rurociągi, komory, węzły itp. Będą one reprezentować rzeczywiste składniki modelowanego systemu i mogą wchodzić ze sobą we wzajemne relacje.

7. Obiekty posiadające atrybuty geometryczne mogą oddziaływać na poziomie topologicznym. Na przykład przewody mogą łączyć się ze sobą i z komorami.

8. Wszystkie obiekty, które mogą ze sobą oddziaływać mają zostać określone poprzez sieć topologiczną.

16. Typowe rodzaje danych

1. System ma umożliwiać jednoczesne wyświetlanie i korzystanie z podkładu rastrowego oraz

z danych wektorowych. Dzięki temu nie będzie konieczności pełnej digitalizacji wszystkich obiektów rastrowych.

2. Zapis i dostęp do rastrów powinien być zrealizowany w bazie danych.

3. Ciągła budowa bazy danych GIS ma pozwolić na całkowitą integrację danych wektorowych

i rastrowych.

17. Dane geograficzne

1. W modelu danych systemu właściwości geometryczne obiektów mają być reprezentowane przy pomocy punktów, linii i obszarów.

2. Punkty będą reprezentować obiekty wymiaru zero. Każdy punkt będzie miał określone 3 współrzędne.

3. Krzywe to uporządkowane kolekcje odcinków, których będzie używało się do reprezentacji obiektów liniowych, takich jak rzeki, drogi, przewody itd.

4. Obszar to obiekt posiadający powierzchnię, czyli np. działka, budynek, terytorium miasta itp.

5. Ważną cechą modelu danych systemu ma być posiadanie przez obiekty bazy danych zdefiniowanych przez użytkownika wielu cech geometrycznych np. budynek może posiadać obrys fundamentów i obrys konstrukcji zewnętrznej.

6. Każdy obiekt w systemie GIS może posiadać nieograniczoną ilość opisujących go cech/atrybutów możliwych do samodzielnego definiowania przez administratora.

7. Do każdego obiektu w systemie GIS istnieje możliwość dodania dowolnej ilości załączników w dowolnym formacie.

8. Geometria obiektu nie musi być elementem obowiązkowym. System musi umożliwiać utworzenie obiektów bez geometrii i dodanie jej do już utworzonego obiektu w dowolnym innym czasie edycji danych obiektu. Przykładowo: jeśli dokładne umiejscowienie na mapie zgłoszonej awarii nie jest jeszcze znane, można utworzyć obiekt awaria z opisem (m.in. lokalizacji), natomiast zaznaczenie na mapie dodać po dokładniejszym ustaleniu miejsca. Warstwa w GIS musi posiadać atrybuty opisowe i geometrię w jednej tablicy, a geometria musi być zapisana w postaci typu przestrzennego SDO_GEOMETRY opcji Oracle Locator lub równoważny w przypadku innej bazy danych.

18. Dane alfanumeryczne i numeryczne (słowniki)

1. Słowniki mają być zastosowane do opisu wielkości nienumerycznych i numerycznych

o ograniczonej licznie dopuszczalnych wartości, takich jak np. nazwy stanów urządzenia („w użyciu", „odłączony", „w remoncie” itp.).

2. Zastosowanie słowników ma pozwolić na kontrolowanie poprawności wprowadzanej przez użytkowników wartości.

3. System musi umożliwiać samodzielne modyfikowanie i uzupełnianie wszystkich dostępnych słowników.

4. System musi umożliwiać wykorzystanie danego słownika do opisu atrybutów dla różnych typów obiektów.

19. Topologia sieci

1. System ma automatycznie utrzymywać i uaktualniać powiązania topologiczne na podstawie reguł określanych w czasie tworzenia modelu danych.

2. Reguły topologiczne mają określić, czy i jak dana para obiektów ze sobą oddziałuje. Na przykład: armatura dzieli sieć na dwa odcinki; dwa odcinki sieci przecinając się nie oddziałują na siebie

(w przypadku przechodzenia przewodów jeden nad drugim), ale już dwa przewody stykające się końcami można uznać za połączone itd.

3. Wszystkie te zależności muszą zostać określone na podstawie reguł, które powinny być zaimplementowane w systemie.

4. Topologia powinna być automatycznie tworzona/modyfikowana podczas wprowadzania /modyfikowania obiektów w bazie danych.

5. W wyniku modyfikacji zawartości bazy danych może nastąpić podział istniejących obiektów, wstawienie nowych węzłów lub (w przypadku braku oddziaływania) zmiany powinny zakończyć się na dodaniu nowego obiektu.

6. Reguły topologiczne mają również być wykorzystywane do wykrywania kolizji nowych obiektów z istniejącymi, na przykład do wykrywania tych miejsc, w których projektowany przewód wodociągowy, kanalizacyjny bądź energetyczny przecina się z istniejącymi instalacjami innego rodzaju.

7. W przypadku istnienia standardowych metod rozwiązywania takich kolizji należy stworzyć ich katalog (szablony protokołów odbioru kolizji z poszczególnymi dysponentami obcej infrastruktury liniowej), który będzie wykorzystywany w takich przypadkach bez potrzeby wymyślania na nowo znanych rozwiązań.

8. Topologia sieci musi uwzględniać stan obiektu i wizualizować obraz sieci w odpowiedzi odpowiednio zgodnie ze zdefiniowanymi regułami (np. stan zaworu: otwarty/ zamknięty: innym kolorem, inną ikoną).

9. Wszystkie reguły edycyjne/topologiczne powinny być zaimplementowane na poziomie bazy danych.

20. Wymiana danych

1. System ma zapewniać szerokie możliwości wymiany danych z innymi systemami informatycznymi.

2. Poza oferowanymi standardowymi metodami konwersji danych istotne będą również narzędzia, które pozwolą na korzystanie z danych przechowywanych w innych formatach bez konieczności wykonywania trwałej translacji (przeniesienia). Funkcjonalność ta może być zapewniona przez zapewnienie odpowiednich modułów stanowiskom typu desktop.

3. Możliwość eksportu i importu (wymiany) danych do/z systemów w różnych formatach,

a co najmniej shp, .txt, .html, .xls ,.xml, dwg, dxf.

4. System musi współpracować z oprogramowaniem biurowym (MS Office, OpenOffice) oraz posiadać możliwość komunikacji z różnymi bazami danych oraz łatwość budowy interfejsów.

5. System musi posiadać możliwość importu danych ewidencyjnych w formacie SWDE.

6. System musi posiadać interfejs pozwalający na podłączenie się do zewnętrznych serwerów WMS w celu pobrania danych i wyświetlenia ich jako osobnych warstw

w systemie.

7. Możliwość zaimportowania pliku tekstowego ze współrzędnymi pikiet wysokościowych.

21. Dostęp do obcych plików on-line

1. System musi umożliwiać wyświetlanie szerokiej gamy formatów danych geograficznych bez konieczności dokonywania konwersji tych danych do wewnętrznego formatu systemu.

2. Mechanizm taki musi umożliwiać obsługę co najmniej kilku następujących formatów danych:

c) Autodesk – DWG,

d) Autodesk – DXF,

e) Bentley – DGN,

f) ESRI – SHP,

g) TIFF - Tagged Image File Format,

h) BMP - Windows Bitmap,

i) JPEG - Joint Photographic Experts Group.

22. Komunikacja z zewnętrznymi bazami danych

1. System powinien zapewniać możliwość wymiany danych on-line oraz off-line z dowolnymi bazami danych zarówno „serwerowymi” jak i „plikowymi” przy pomocy własnych mechanizmów lub driverów ODBC, bazy danych mogą być relacyjne i nierelacyjne (płaskie, obiektowe) (szczególnie dla Oracle, MS-SQL, Access, DBF, Tekst, XML, Excel).

2. System powinien zapewniać możliwość wymiany danych on-line przez mechanizmy systemu, interfejsy lub mechanizmy uniwersalne (ODBC) z systemami opartymi

o relacyjne bazy danych.

23. Interfejs użytkownika

1. System musi umożliwiać pełne dostosowywanie interfejsu tzn. usuwanie/dodawanie /grupowanie pól ekranowych, zmianę ich wymagalności, etykiet, kolejności na ekranie

i układu ekranu, dodawanie i usuwanie zakładek, możliwość wyszukiwania informacji wg dowolnie wybranych pól opisowych bez znajomości języka programowania.

2. System ma umożliwiać, przy wykorzystaniu odpowiednich narzędzi, dostosowanie aplikacji

w sposób umożliwiający zwiększanie funkcjonalności systemu i tworzenie innych wyspecjalizowanych (szytych na miarę) stanowisk przez pracowników przedsiębiorstwa bez konieczności ingerencji dostawcy systemu.

3. Przy pomocy stosownych mechanizmów zaoferowanych przez system musi istnieć możliwość zdefiniowania wszystkich obiektów w systemie, rodzajów relacji pomiędzy nimi, reguł topologicznych sieci i innych, bez konieczności pisania kodu (programowania).

4. System ma bazować na graficznym, okienkowym interfejsie użytkownika.

5. Dostęp do odpowiednich funkcji menu ma być uwarunkowany poprzez przypisane uprawnienia dla użytkownika lub grupy użytkowników.

6. Użytkownik ma mieć możliwość definiowania i zapamiętywania na stałe wyglądu

i zawartości interfejsu.

7. Administrator ma mieć możliwość definiowania, zapamiętywania i przypisywania na stałe wyglądu i zawartości interfejsu dla wybranego użytkownika, grupy użytkowników lub wszystkich.

24. Biblioteki symboli

1. System stylów systemu ma umożliwiać uprawnionemu użytkownikowi całkowitą kontrolę nad reprezentacją graficzną dowolnych obiektów na mapie branżowej.

2. Obiekty liniowe, takie jak odcinki sieci ciepłowniczej, przedstawiane są liniami, którym można nadać dowolny kolor, grubość i wzór.

3. Obiekty obszarowe, takie jak np. miasto, mogą mieć własny kolor, wzór granicy oraz wzór wypełniający.

4. Symbole przechowywane mają być w bibliotekach symboli dostępnych dla wszystkich uprawnionych użytkowników.

5. Jeśli symbol ulegnie zmianie, to musi zmienić się jego reprezentacja graficzna we wszystkich aplikacjach wchodzących w skład systemu GIS używających tego symbolu.

6. System ma umożliwiać dostosowywanie się prezentacji graficznej i jej symboli

w zależności od skali prezentacji (definiowanie, co ma się pojawiać na mapach w danej skali) – każdy użytkownik może posiadać własne ustawienia.

7. Dla mapy zasadniczej symbolika elementów ma być zgodna z instrukcją geodezyjną K-1 „Zasadnicza mapa kraju".

8. O ile to możliwe symbolika mapy branżowej ma być zgodna z instrukcją geodezyjną

K-1 oraz G-7.

25. Zapytania ad-hoc

1. Standardową funkcją systemu ma być wspomaganie tworzenia szybkich zapytań, które mogą dotyczyć także atrybutów przestrzennych lub powiązań między obiektami.

2. Narzędzia dostarczone wraz z systemem mają być jak najbardziej ogólne i pozwalać operatorowi na wprowadzanie dowolnej kombinacji zadawanych pytań.

3. Będzie musiała być zapewniona możliwość zaprogramowania tych zapytań, których wyniki będą często wykorzystywane w pracy służb przedsiębiorstwa tak, aby tworzenie raportów wymagało jak najmniejszego wysiłku ze strony użytkownika systemu.

4. System przy tworzeniu zapytań geograficznych ma opierać się na okienkach

z podpowiedziami (kreator).

5. Użytkownik będzie wybierał kolejne pozycje z przedstawianych mu list i odpowiadał na pytania, których ostatecznym wynikiem ma być zapytanie zadawane bazie danych.

6. Język używany w zapytaniach ma stanowić rozszerzenie składni SQL o możliwości tworzenia zapytań przestrzennych, rozstrzygających takie zależności przestrzenne jak zawieranie się, przyleganie, przecinanie, nakładanie, stykanie itp.

7. Gotowe zapytania oraz ich wyniki będzie można zapisywać do późniejszego wykorzystania.

8. Poza tworzeniem zapytań z ww. poziomu, musi istnieć możliwość wpisywania wprost tekstu zapytania w języku SQL.

9. Wyniki zapytań mogą być wyświetlane na mapie, przesyłane do generatora raportów, przekazywane innym aplikacjom lub zachowane do użycia w przyszłości.

26. Rastry

1. System musi dostarczyć narzędzia służące do konwersji danych graficznych, zarówno rastrowych jak i wektorowych.

2. Obsługa co najmniej georeferencyjnych danych rastrowych w formacie TIFF i CIT.

3. Możliwość importu map rastrowych bez georeferencji i samodzielne nadawanie jej

w programie

4. Poza monochromatycznymi mapami rastrowymi system musi również wykorzystywać rastry kolorowe oraz zdjęcia lotnicze.

27. Wektor

1. System poza obsługą formatu wektorowego SHP musi umożliwiać import danych

z formatów używanych przez inne systemy oprogramowania (co najmniej DWG, DXF, DGN).

2. System ma zapewniać tzw. konwertery do zewnętrznych formatów: DXF, SHP, TXT, XLS, MDB.

28. Układy współrzędnych

1. System ma pracować w układzie współrzędnych 2000.

2. System ma obsługiwać wiele różnych systemów projekcji mapy (układów współrzędnych).

3. System ma mieć możliwość korzystania dodatkowo co najmniej z następujących układów współrzędnych:

i) 1992,

j) 1965,

k) WGS84 geograficznych: Dł., Wys., Szer.

4. Mają być dostępne co najmniej następujące funkcje systemu:

a) możliwość dokonywania konwersji pomiędzy różnymi układami współrzędnych,

w tym konwersji w locie,

b) możliwość eksportu i importu danych w układzie współrzędnych innym niż użyty

w bazie danych GIS,

c) podawanie współrzędnych punktów w innych układach współrzędnych niż użyty

w bazie danych,

d) wyświetlanie treści mapy w dowolnie wybranym (spośród zdefiniowanych) układzie współrzędnych.

29. Wybór treści – wyszukiwanie obiektów

1. System ma zapewniać szerokie możliwości wyboru zawartości przeglądanych danych takie jak chociażby:

a) Dające się dostosować skalowanie widoku z automatycznym wyborem rodzajów

i wyglądu obiektów, które będą widoczne w predefiniowanych przedziałach skali. Pozwoli to na uniknięcie zbyt dużego zagęszczenia obiektów wyświetlanych zwłaszcza w małej skali (przy dużym oddaleniu).

b) Przesuwanie ze stosowaniem rozmaitych kryteriów (płynne, do wskazanego punktu, wzdłuż definiowanego obiektu, itp.) oparte na założeniach DDC (Dynamic Display Cache) lub innej równoważnej technologii.

c) Generowanie map tematycznych – na podstawie dostępnych danych można wygenerować nową tablicę, a graficzną reprezentację jej zawartości przedstawić na mapie i/lub wydruku.

d) Obiekty z bazy danych będzie można wybierać bezpośrednio z mapy lub wyszukiwać przy pomocy dostępnych w systemie narzędzi. Będzie można przy tym korzystać z języka zapytań opartego na języku SQL i uzupełnionego o możliwości wykonywania zapytań przestrzennych.

2. System ma umożliwiać tworzenie własnych zapytań przy użyciu menu, tablic itp., co wyeliminuje konieczność uczenia się nowych składni.

3. Wyniki wyszukiwania wśród danych alfanumerycznych będzie można przedstawić na mapie w postaci graficznej.

4. Zapytania przestrzenne mają mieć możliwość zagnieżdżania wyniku jednego zapytania dla przygotowania drugiego zapytania opartego o uzyskany wynik.

5. Można również wybierać obiekty z mapy, odczytując ich atrybuty niegeometryczne oraz informacje o obiektach związanych w jakiś sposób z danym obiektem.

30. Analizy sieciowe

1. System ma zapewniać wiele funkcji do wykonywania analiz przestrzennych i sieciowych.

2. Podstawowe moduły do analiz sieciowych mają pozwalać m.in na:

a) prezentację obszaru pozbawionego dostaw ciepła, wyniku awarii lub zamknięcia zasuw,

b) znajdowanie źródeł zasilania dla węzła,

c) znajdowanie fragmentu sieci spełniającego podane kryteria (np.: te fragmenty sieci

o zadanej średnicy, które znajdują się w określonej odległości od punktu wskazanego jako początkowy),

d) odpowiednią prezentację graficzną wyników zapytań.

3. Możliwie jak najszerzej rozumiana złożoności kryteriów dla przeprowadzanych analiz.

4. Musi istnieć możliwość wykonania śledzenia sieci, które wykorzysta funkcję kosztu (na przykład śledzenie wzdłuż projektowanej trasy przewodu, które określi koszt jego budowy).

5. Znalezione fragmenty sieci będzie można również wyświetlić w głównym oknie aplikacji na tle pozostałych danych z odpowiednim ich rozróżnieniem (np. pogrubienie, podświetlenie, inny kolor).

6. Standardowe funkcje systemu mają pozwalać na lokalizację dowolnego obiektu przy pomocy kombinacji jego atrybutów.

7. Zapytania tego typu mają używać między innymi funkcji śledzących i przestrzennych, dzięki czemu nie trzeba przechowywać w jawnej postaci danych o powiązaniach. Np. można znaleźć punkt zasilający, do którego przyłączony jest (pośrednio) klient

o wskazanym adresie wykonując śledzenie trasy od tego adresu i wskazując pierwszy znaleziony punkt zasilający. Nie trzeba nigdzie zapisywać, którzy klienci są podłączeni, do którego źródła należą.

31. Tworzenie raportów

1. System musi posiadać generator raportów pozwalający na tworzenie szablonów raportów, które następnie będzie można zapisać i wykorzystywać np. w późniejszym czasie. Generator raportów może być oddzielną aplikacją, lecz nie może posiadać limitu co do ilości użytkowników.

2. Tworzenie raportów powinno polegać na wygenerowaniu sformatowanego raportu używając do tego celu wskazanego szablonu i wskazanych danych.

3. Musi istnieć możliwość wykorzystania do raportu danych uzyskanych w wyniku wykonanego wcześniej śledzenia, zapytania lub analizy.

4. Raporty będą mogły zawierać dowolne kombinacje pól wybranych rekordów wraz

z pozycjami specjalnymi (takimi jak sumy czy średnie) oraz dowolne dane pochodzące z systemu.

5. Raporty będzie można zapisywać do pliku na dysku twardym (ta sama funkcjonalność dla zbiorów obiektów otrzymanych w wyniku zapytań).

6. Musi istnieć możliwość eksportu danych z raportów do edytorów tekstu lub arkuszy kalkulacyjnych.

7. Narzędzie do tworzenia raportów nie może posiadać ograniczenia co do ilości użytkowników z niego korzystających.

8. Aplikacja WWW i aplikacja desktop musi umieć odczytywać ten sam szablon raportu w obu aplikacjach. Raz utworzony szablon będzie prezentował dane identycznie

w dowolnej aplikacji.

32. Drukowanie i plotowanie

1. System ma drukować wszelkie dane w nim zgromadzone oraz dane importowane do GIS

z innych systemów.

2. Użytkownik musi mieć możliwość podjęcia decyzji, które z obiektów przedstawione na mapie GIS znajdą się na wydruku.

3. Menadżer wydruków ma umożliwiać dokładanie do wydruków adnotacji i symboli oraz umożliwiać umieszczenie na wydruku dowolnych obrazów z zewnętrznych plików.

4. Drukowanie ma odbywać się w formatach odpowiednich dla drukarek i ploterów znajdujących się obecnie na rynku (co najmniej w zakresie od A4 do A0) z możliwością definiowania własnych rozmiarów.

5. Standardowym elementem menadżera wydruków ma być narzędzie do oglądania planowanych wydruków pozwalające operatorowi na przyjrzenie się wydrukowi w takiej postaci, w jakiej trafi on do drukarki lub plotera, z uwzględnieniem wzorca ramki, adnotacji, symboliki.

6. System powinien posiadać możliwość drukowania obiektu na oddzielnych arkuszach z zakładką.

33. Aplikacja Desktop GIS:

Należy dostarczyć 2 licencje jednoczesnego użytku aplikacji desktop GIS.

Wykaz podstawowych funkcjonalności dla aplikacji Desktop GIS:

legenda mapy: dokowana do okna programu, grupowanie warstw w legendzie mapy, menu podręczne legendy na prawym przycisku myszy, ustawianie właściwości warstw po wybraniu pozycji na legendzie, powiększenie mapy do bieżącej warstwy, prezentacja metadanych warstwy (zasięg, źródło danych),

narzędzia nawigacji po mapie: cała mapa, pomniejszanie, powiększanie, panoramowanie (przesuwanie mapy), przejście do punktu o zadanych współrzędnych, okno nawigacji, przejście do obszaru roboczego,

dodawanie do mapy warstwy z pikietami wysokościowymi, których współrzędne Z wykorzystywane są przez system w trakcie rysowania sieci (system ma podpowiadać współrzędną Z obiektu jako współrzędną Z najbliższej pikiety)

konfigurowanie dynamicznych opisów (tooltip dla dowolnego obiektu),

tworzenie obszarów roboczych, filtracja mapy wg obszarów,

identyfikacja obiektów na mapie z możliwością przejścia do edycji elementu,

edycja obiektów dowolnej edytowalnej warstwy, przejście do wstawiania geometrii,

pomiar odległości i pomiar powierzchni,

wyszukiwanie i selekcja danych wg geometrii, szybkie narzędzia selekcji z menu głównego (wewnątrz prostokąta, wieloboku, wokół punktu, cały ekran), kasowanie bieżącej selekcji,

wyszukiwanie i selekcja wg atrybutów opisowych,

funkcje sieciowe i nadawanie miar (szukanie punktu o zadanej mierze w trasie, wskazywanie miary dla zadanego punktu).

dodawanie własnych atrybutów obiektów,

dodawanie atrybutów będących wynikiem obliczeń na podstawie innych atrybutów obiektu

tworzenie nowych warstw shapefile i warstw bazodanowych, wykorzystanie istniejących warstw jako wzorców,

pasek narzędzi edycyjnych konfigurowanych przez użytkownika,

statystyka na warstwach, statystyka na tablicach opisowych, tworzenie wykresów, zapamiętywanie konfiguracji,

menu główne oraz konfigurowalne menu dla danych opisowych, formatka typu drzewo nawigacji,

menu podręczne na prawym przycisku myszy na mapie w tym funkcje: pomniejszanie, powiększanie identyfikacja, edycja obiektu na bieżącej warstwie, wyszukanie i wybór innych edytowalnych obiektów na mapie w pobliżu,

wielofunkcyjna formatka z danymi opisowymi: w tym podział danych na zakładki, geometria jako jedna z zakładek, prezentacja i edycja danych z tablic podrzędnych na zakładce,

funkcje nawigacji po danych w rekordach, przejście do rekordu o zadanym numerze, podświetlanie obiektu, podświetlanie poprzedniego kształtu obiektu, wyróżnianie kolorem, panoramowanie do obiektu (przesuwanie), powiększanie do obiektu,

funkcje wstawiania, wycofania zmian, zapisu, odświeżania, usuwania danych, zapis wszystkich zmian w zbiorze rekordów, usunięcie wszystkich rekordów,

filtracja danych na formatce, filtrowanie tylko spośród już wybranych danych, filtracja dla pojedynczych dat, przedziałów dat,

funkcja kolorowania wierszy w widoku zbiorczym w zależności od parametru np. wartości w kolumnie, kolorowanie pól na formularzu w zależności od parametru np. wartości przekroczenia,

selekcja wszystkich obiektów na mapie z formatki, selekcja tylko bieżącego rekordu, operacje na zbiorze selekcji (nowy, dodawanie, odejmowanie),

listy wyboru, w tym listy z danymi multimedialnymi, stale widoczne przyciski list,

data wprowadzana z kalendarza lub ręcznie, wybieranie z mapy zamiast listy

z ograniczeniami przestrzennymi, autouzupełnianie jeśli tylko jedna pozycja na liście,

widok zbiorczy danych, sortowanie danych, eksport do html, lista z danymi hierarchicznymi (typu master – detail), możliwość eksportu do Excela (XLS,XLSX),

edycja danych geometrycznych przez menu kontekstowe na mapie,

edycja geometrii przez dociąganie do wielu warstw jednocześnie, priorytet konfigurowalny – decyduje kolejność, każda pozycja dociągania ma indywidualne właściwości,

narzędzia edycji geometrii: rozdwajanie linii, generalizacja linii, odwracanie kierunku linii (wraz z przepisaniem/zachowaniem atrybutów),

narzędzia domiarowania – dokładne wyznaczanie punktów i pomocniczych kresek domiarowych, zapis domiarów do warstw,

import danych z pliku tekstowego do warstw z możliwym dowolnym układem kolumn

w pliku,

eksport widoku mapy z georeferencjami do bmp, eksport do JPG, ustawianie parametrów eksportu i jakości obrazu,

podgląd wydruku, ustawienia wydruku, rozbudowane adnotacje, wydruk do pliku (zamiast do drukarki), wydruk do EMF – wektorowy obraz o jakości wydruku,

pomoc ogólna, pomoc kontekstowa (związana z bieżącą formatką), możliwość tworzenia pomocy branżowej – kontekst wynika z bieżącego rodzaju danych na formatce opisowej,

Interfejs oraz system pomocy w języku polskim.

Aplikacja desktop GIS musi posiadać narzędzia do szybkiej edycji topologicznej posiadające funkcje:

grupowego dzielenia odcinków sieci w węzłach (selekcja węzłów na mapie, które podzielą sieć),

grupowego dociągania węzłów do sieci (selekcja węzłów, które zostaną grupowo dociągnięte),

grupowego dociągania węzłów i dzielenia sieci (selekcja węzłów, które zostaną grupowo dociągnięte i sieć zostanie automatycznie podzielona).

Narzędzie musi posiadać konfigurator, w którym będzie można podać promień dociągania węzłów do sieci oraz będzie można określić, jakie węzły mogą dzielić jaką sieć. Konfiguracja musi być zapamiętana jako dedykowane przyciski dla użytkownika. Użytkownik sam wybiera ikonkę przycisku.

Narzędzia do zaawansowanej edycji topologicznej muszą posiadać funkcje:

konfiguracji relacji pomiędzy obiektami sieci i węzłów w zakresie określenia czy węzeł ma dzielić sieć, czy tylko ma się dociągać,

konfiguracji wykluczeń jakie węzły nie mogą dzielić sieci i nie mogą się dociągnąć,

konfiguracji dedykowanych przełączników umożliwiających wybieranie atrybutów jako ikonek podczas edycji geometrii, użytkownik sam może zdefiniować, jaki atrybut zdefiniuje za pomocą przełącznika oraz może sam określić ikonkę przełącznika, podczas edycji użytkownik może zmienić przełącznik tym samym zmieniając atrybut, przełączników może być dowolna ilość dla dowolnej liczby atrybutów,

konfiguracji zachowań się obiektów podczas podziału sieci lub scalania sieci

z określeniem, jakie atrybuty system ma przepisywać podczas podziału i jakie atrybuty ma uzgadniać podczas scalania sieci o różnych parametrach, wartość przepisywana może być z dzielonego obiektu lub może posiadać określony stały parametr.

Podczas scalania sieci system ma się zapytać jakie atrybuty należy przyjąć w przypadku różnych wartości.

Wszystkie konfiguracje muszą być wykonywane z poziomu interfejsu użytkownika

i zapisywane w jego ustawieniach lub w bazie danych. Konfigurację można odczytać z bazy danych. Dowolny użytkownik będzie mógł odczytać konfigurację z bazy danych od innego użytkownika.

Podczas edycji topologicznej można podać długość edytowanego odcinka, kąt następnego segmentu.

System po wprowadzeniu odcinka musi automatycznie zaproponować, jaki węzeł należy wstawić na końcu odcinka. Wybrany węzeł musi posiadać przełączniki z typami węzła lub atrybutami np. przełącznik określający średnicę studzienki, użytkownik zaznacza tylko ikonkę średnicy DN1000 bez wpisywania z klawiatury tych wartości. Po wprowadzeniu węzła następuje kontynuacja rysowania sieci od wprowadzonego węzła bez konieczności zamykania okna edycyjnego. Użytkownik za pomocą 1 formularza edycji topologicznej będzie mógł edytować cały ciąg obiektów punktowo - liniowych, które wcześniej skonfigurował

w konfiguratorze topologii.

Modyfikacja sieci lub węzła spowoduje modyfikację obiektów dociągniętych, przesunięcie węzła spowoduje przesunięcie sieci.

Użytkownik podczas edycji topologicznej na formularzu edycji może zmieniać promień dociągania lub wyłączyć dociąganie, jeżeli będzie taka potrzeba.

MODUŁY BIZNESOWE

34. Wspomaganie wydawania warunków technicznych – WT (przeglądarka WWW)

Moduł WT będzie wspierał proces wydawania warunków technicznych od złożenia wniosku do wydania pisma do klienta.

Moduł WT musi posiadać następujące funkcjonalności:

rejestracja klientów (osoby fizyczne, prawne),

możliwość importu danych klienta z innego systemu informatycznego (np. systemu ERP) lub powiązanie danych wprowadzonego w systemie GIS klienta z klientem systemu ERP

i wyświetlanie danych z systemu ERP w formatce oprogramowania GIS (wg wcześniej ustalonego schematu),

rejestracja wniosków (opracowania warunków technicznych),

rejestracja skanu planu sytuacyjnego,

rejestracja statusu wniosku:

wniosek przyjęty,

wniosek odrzucony,

wniosek zarejestrowany,

historia statusów wniosków,

lista wniosków WT do realizacji,

opracowanie Warunków Technicznych,

statusy WT:

• opracowywanie Warunków Technicznych,

• warunki gotowe do zatwierdzenia,

• warunki zatwierdzone,

• warunki odrzucone,

wnioski WT, opracowania – widok zbiorczy,

wydawanie pism dokumentów WT,

projektowanie warstw wraz z szacunkowym nakładem,

wydruk planu sytuacyjnego,

dostęp do danych miejskich i branżowych,

konfigurowalne szablony dokumentów treści pism.

35. Wspomaganie obsługi uzgodnień lokalizacyjnych – UL (przeglądarka WWW)

Moduł UL będzie wspierał proces obsługi uzgodnień lokalizacyjnych od złożenia wniosku do wydania pisma do klienta.

Moduł UL musi posiadać następujące funkcjonalności:

rejestracja klientów (osoby fizyczne, prawne).

możliwość importu danych klienta z innego systemu informatycznego (np. systemu ERP) lub powiązanie danych wprowadzonego w systemie GIS klienta z klientem systemu ERP

i wyświetlanie danych z systemu ERP w formatce oprogramowania GIS (wg wcześniej ustalonego schematu),

rejestracja wniosków (o uzgodnienie kolizji).

rejestracja statusu wniosku:

• wnioski przyjęte (w fazie rejestrowania),

• wnioski z wyznaczonym obszarem uzgodnienia (w fazie rejestrowania),

• wnioski zarejestrowane,

wydruk rejestru wniosków,

przestrzenna rejestracja obszarów uzgodnień,

rejestracja wydawanych uzgodnień,

automatyczne przeszukiwanie warstw branżowych celem wyszukania obiektów kolidującym

z obszarem uzgodnienia,

identyfikacja statusu uzgodnienia:

• przyjęty do ewidencji uzgodnień,

• określono status kolizji,

• dokumenty wydane klientowi,

• dokumenty przekazane do MPEC,

wydawanie pism-odpowiedzi (kolizja, brak kolizji), uwagi,

wydruk rejestru uzgodnień,

dostęp do danych miejskich i branżowych,

sprawozdania okresowe z wydanych uzgodnień,

konfigurowalne treści pism.

36. Wspomaganie obsługi służebności –OS (przeglądarka WWW)

Program musi umożliwiać rejestrowanie spraw związanych z wnioskami o ustanowienie służebności oraz musi wspomagać w wyliczeniu wysokości służebności na podstawie analiz położenia obiektów sieci ciepłowniczej na działkach.

Moduł OS musi posiadać następujące funkcjonalności:

Obsługa przez przeglądarkę internetową.

Rejestracja nowych spraw o ustanowienie służebności, nadawanie i zmiany statusu sprawy.

Oznaczanie informacji wymaganych dla nowej sprawy.

Ewidencja klientów.

Wybór klienta dla sprawy z ewidencji klientów.

Możliwość wyszukania klienta po dowolnych jego parametrach.

Rejestracja działek dotyczących sprawy.

Podczas wprowadzania danych działki system umożliwi wybór z listy lub wpisanie ręcznie pełnego numeru działki oraz w przypadku pozostawienia niewypełnionych atrybutów zostaną one wypełnione informacjami pobranym z działki z systemu GIS

(o ile takie informacje istnieją).

Aplikacja umożliwi wprowadzenie ilości sieci na działce oraz powierzchni komór, a także system pobierze dane pochodzące z analizy sieci na działkach (długości sieci na działce, powierzchnia komór).

System wyliczy powierzchnię pasa pod siecią ciepłownicza oraz wartość służebności.

System umożliwi dodawanie dowolnych dokumentów do sprawy.

Wyszukiwanie i prezentacja obiektów sieciowych położonych w granicach danej nieruchomości/działki.

System umożliwi wizualizację na mapie różnych statusów spraw.

System potrafi wyznaczyć listę działek o nieuregulowanej służebności na których zlokalizowane są obiekty sieciowe objęte inwestycją lub obiekty planowanej sieci.

37. Integracja z obecnie posiadanymi systemami – ERP – Środki Trwałe

1. System GIS na podstawie przypisanego do danego obiektu numeru ewidencyjnego środka trwałego będzie pokazywał informacje zgromadzone o nim w systemie ERP:

a) wartość,

b) amortyzacja,

c) opis ŚT,

d) klasyfikacja ŚT,

e) osoba odpowiedzialna.

2. Wykonawca utworzy warstwę amortyzacji, w której obiekty będą wyświetlane w kolorach odpowiadających zakresowi stopnia amortyzacji. Kolor dla danego stopnia amortyzacji będzie definiowany przez Zamawiającego.

3. System będzie w stanie wygenerować mapę z zaznaczonymi obiektami wskazanego typu/typów, które nie są powiązane z żadnym środkiem trwałym.

4. System będzie generował definiowalne raporty uwzględniające m.in. stopień amortyzacji obiektów lub braku przypisania obiektu do środka trwałego.

5. Przypisanie/powiązanie środka trwałego z obiektami w GIS wykona Zamawiający.

6. Informacje o środkach trwałych pobierane będą za pomocą integracji z systemem ERP. Nie przewiduje się przekazywania danych do systemu środków trwałych z systemu GIS.

7. Niezbędne dane potrzebne do integracji wystawione zostaną z systemu ERP. Koszty udostępniania tych danych poniesie Zamawiający.

38. Sieci alarmowe

1. Zarządzanie elementami sieci alarmowej: Obwód alarmowy, Alarm, Detektor, Moduł komunikacyjny, Element sieci alarmowej, wraz ze słownikami rodzajów i typów.

2. Możliwość wprowadzania Alarmów, które wystąpiły na sieci (wraz z pozycją na mapie). Dla każdego alarmu definiowany jest status obsługi oraz czasy zgłoszenia i rozwiązania problemu.

3. Podświetlanie na mapie w różnych kolorach odcinków należących do obwodów alarmowych.

II. Oprogramowanie GIS przeznaczone jest do zadania współfinansowanego ze środków Unii Europejskiej w

ramach Programu Operacyjnego Infrastruktura i Środowisko, oś priorytetowa 9 "Infrastruktura Energetyczna

Przyjazna Środowisku i Efektywność Energetyczna", działanie 9.2 „Efektywna dystrybucja energii”, projekt pn.

„Ograniczenie strat i poprawa pewności dostaw ciepła poprzez modernizację sieci ciepłowniczej w Tarnowie”.

IV. Oferty równoważne:

IV.I. Ilekroć w opisie przedmiotu zamówienia wskazane zostały normy, aprobaty, specyfikacje techniczne,

systemy odniesienia, producent, typ itp. Zamawiający dopuszcza rozwiązania równoważne opisywanym.

IV. II. Za ofertę równoważną uznana zostanie ta oferta, która zawierać będzie przedmiot zamówienia o

parametrach co najmniej takich samych bądź bardziej korzystnych

w stosunku do parametrów, które podane są w opisie przedmiotu zamówienia.

IV.III. Na Wykonawcy spoczywa ciężar dowiedzenia równoważności oferty poprzez załączenie do niej

odpowiednich dokumentów potwierdzających równoważność

IV.IV. W przypadku złożenia przez Wykonawcę oferty równoważnej, Zamawiający przed ostatecznym

zakwalifikowaniem oferty do dalszego udziału w postępowaniu podda ją ocenie pod kątem spełnienia wymogu,

o którym mowa w pkt. IV.II.

IV.3.4) Termin składania ofert lub wniosków o dopuszczenie do udziału w postępowaniu:

28.5.2015 (10:00)

IV.3.7) Warunki otwarcia ofert:

28.5.2015 (10:30)

Powinno być: 

II.1.5) Krótki opis zamówienia lub zakupu:

I. Szczegółowy opis przedmiotu zamówienia:

1. Podstawowe założenia architekturalno – funkcjonalne

1. System ma zapewnić uproszczenie i optymalizację:

a) ewidencji infrastruktury sieciowej,

b) rejestracji i obsługi procesu wydawania warunków technicznych, uzgodnień terenowych i obsługi służebności,

c) analiz,

2. System ma być oparty na otwartej i rozwojowej architekturze – także dla Zamawiającego. Oznacza to, że konfiguracja systemu powinna być modyfikowalna przez Zamawiającego za pomocą intuicyjnych graficznych narzędzi oraz narzędzi programistycznych.

3. System ma być budowany zgodnie z założeniami OpenGIS i OGC (Open Geospatial Consortium) oraz dyrektywą unijną INSPIRE.

4. Program musi być zbudowany w architekturze trójwarstwowej opartej na serwerze danych przestrzennych, serwerze aplikacyjnym i „cienkim” kliencie. Wyjątkiem mogą być stanowiska edycyjne (desktop), które mogą być oparte o „grubego klienta”.

5. Program i narzędzia administracyjne systemu muszą pozwalać na zdalną administrację systemem i muszą umożliwiać samodzielny rozwój systemu: między innymi dodawanie nowych pól, słowników, elementów graficznych, dodawanie nowych tabel, definiowanie pól wyliczalnych, budowanie relacji między tabelami – wszystko bez konieczności programowania,

z wykorzystaniem narzędzi wizualnych.

6. System ma być zbudowany w architekturze, której otwartość pozwoli integrować się

w oparciu o powszechnie stosowane mechanizmy wymiany danych.

7. System ma zapewnić mechanizm, dzięki któremu nie będzie trzeba indywidualnie konfigurować oprogramowania na każdej stacji roboczej użytkownika, ale będzie możliwe centralne tworzenie konfiguracji dla poszczególnych użytkowników, grupy użytkowników lub dla wszystkich.

8. System ma umożliwiać wykonywanie zapytań (analiz, raportów) poprzez ogólne mechanizmy bazodanowe (co najmniej SQL) w oparciu o intuicyjny interfejs graficzny.

9. System musi mieć możliwość tworzenia aplikacji GIS w wersji off-line z aktualnymi danymi dla użytkowników pracujących w terenie bez konieczności dostępu do wersji on-line. System musi posiadać mechanizm synchronizacji danych z wersji off-line z danymi z wersji on-line oraz w drugim kierunku.

10. System musi zapewniać bezpieczny dostęp on-line do aplikacji poprzez sieć Internet

z wykorzystaniem przeglądarki internetowej.

11. System musi integrować się z posiadanymi przez Zamawiającego aplikacjami: ERP (środki trwałe), oprogramowaniem do obliczeń hydraulicznych (TERMIS).

12. System musi umożliwiać definiowane miejsca przechowywania załączników (grafika, wideo, inne) w zależności od ich rodzaju i rozmiaru, albo w bazie danych albo poza nią.

2. Opis ogólny systemu

1. System ma obsługiwać w jednolity sposób zarówno dane opisowe jak i geometryczne ewidencjonowanych elementów sieci ciepłowniczej wraz z prezentacją na tle podkładów (rastrowych, wektorowych i rastrowo-wektorowych) oraz obsługiwać ich przejścia w obie strony (uzyskiwanie grafiki od strony opisu i na odwrót).

2. System dzięki integracji z innymi aplikacjami, ma stanowić jeden z elementów systemu informatycznego przedsiębiorstwa.

System ma przechowywać dane w jednej centralnej bazie systemu – Oracle 12c Standard Edition One z licencją na 1 procesor lub równoważnej spełniającej wszystkie cechy w/w bazy danych.

Za bazę równoważną uważa się bazę danych spełniającą poniższe wymagania

— Baza danych musi zapewniać bezpieczne gromadzenie oraz autoryzowany dostęp do danych przestrzennych i opisowych, funkcje indeksowania oraz poprawnego, topologicznego zapisu danych przestrzennych, zgodnie ze standardem OpenGIS Implementation Specification Geographic Information - Simple feature SQL for Binary Geometry, Types and Functions.

— Baza danych musi pracować na systemach operacyjnych co najmniej: Linux 32-bit i 64-bit, MS Windows 32-bit i 64-bit. Baza danych musi zapewniać identyczną funkcjonalność niezależnie od w/w platformy

— Musi umożliwiać przeniesienie (migrację) struktur Bazy Danych i danych pomiędzy ww. platformami bez konieczności rekompilacji aplikacji bądź migracji środowiska aplikacyjnego.

— Modyfikowanie wierszy nie może blokować ich odczytu, z kolei odczyt wierszy nie może ich blokować do celów modyfikacji. Jednocześnie spójność odczytu musi gwarantować uzyskanie rezultatów zapytań odzwierciedlających stan danych z chwili jego rozpoczęcia, niezależnie od modyfikacji przeglądanego zbioru danych.

— Baza danych musi umożliwiać zagnieżdżanie transakcji - powinna istnieć możliwość uruchomienia niezależnej transakcji wewnątrz transakcji nadrzędnej (np. powinien być możliwy następujący scenariusz: każda próba modyfikacji tabeli X powinna w wiarygodny sposób odłożyć ślad w tabeli dziennika operacji, niezależnie czy zmiana tabeli X została zatwierdzona czy wycofana).

— Baza danych musi umożliwiać wsparcie dla wielu ustawień narodowych i wielu zestawów znaków (włącznie z Unicode).

— Baza danych musi zapewniać możliwość migracji zestawu znaków bazy danych do Unicode.

— Musi istnieć możliwość skalowania rozwiązań opartych o architekturę trójwarstwową: możliwość uruchomienia wielu sesji bazy danych przy wykorzystaniu jednego połączenia z serwera aplikacyjnego do serwera bazy danych.

— Musi być możliwe otworzenie wielu aktywnych zbiorów rezultatów (zapytań, instrukcji DML) w jednej sesji bazy danych.

— Baza danych musi być zgodna ze standardem ANSI/ISO SQL 2003 lub nowszym.

— Baza danych nie może posiadać formalnych ograniczeń na liczbę tabel i indeksów oraz na ich rozmiar (liczbę wierszy).

— Baza danych musi posiadać wsparcie dla procedur i funkcji składowanych.

— Baza danych musi posiadać możliwość kompilacji procedur składowanych w bazie do postaci kodu binarnego (biblioteki dzielonej).

— Baza danych musi posiadać możliwość deklarowania wyzwalaczy (triggerów) na poziomie instrukcji DML (INSERT, UPDATE, DELE-TE) wykonywanej na tabeli, poziomie każdego wiersza modyfikowanego przez instrukcję DML oraz na poziomie zdarzeń bazy danych (np. próba wykonania instrukcji DDL, start serwera, stop serwera, próba zalogowania użytkownika, wystąpienie specyficznego błędu w serwerze). Ponadto mechanizm wyzwalaczy powinien umożliwiać oprogramowanie obsługi instrukcji DML (INSERT, UPDATE, DELETE) wykonywanych na tzw. niemodyfikowalnych widokach (views).

— W przypadku, gdy w wyzwalaczu na poziomie instrukcji DML wystąpi błąd zgłoszony przez motor bazy danych bądź ustawiony wyjątek w kodzie wyzwalacza, wykonywana instrukcja DML musi być automatycznie wycofana przez serwer bazy danych, zaś stan transakcji po wycofaniu musi odzwierciedlać chwilę przed rozpoczęciem instrukcji w której wystąpił ww. błąd lub wyjątek.

— Baza danych musi posiadać możliwość autoryzowania Użytkowników za pomocą rejestru Użytkowników założonego w Bazie Danych.

— Baza Danych musi umożliwiać na wymuszanie złożoności hasła Użytkownika, czasu życia hasła, sprawdzanie historii haseł, blokowanie konta (przez Administratora bądź po przekroczenia limitu nieudanych logowań).

— Przywileje Użytkowników Bazy Danych muszą być określane za pomocą przywilejów systemowych (np. prawo do podłączenia się do Bazy Danych - czyli utworzenia sesji, prawo do tworzenia tabel itd.) oraz przywilejów dostępu do obiektów aplikacyjnych (np. odczytu/modyfikacji tabeli, wykonania procedury).

— Baza Danych powinna umożliwiać nadawanie ww. przywilejów za pośrednictwem mechanizmu grup użytkowników / ról bazodanowych. W danej chwili użytkownik może mieć aktywny dowolny podzbiór nadanych ról bazodanowych.

— Musi istnieć możliwość wykonywania i katalogowania kopii bezpieczeństwa bezpośrednio przez serwer Bazy Danych. Możliwość zautomatyzowanego usuwania zbędnych kopii bezpieczeństwa przy zachowaniu odpowiedniej liczby kopii nadmiarowych - stosownie do założonej polityki nadmiarowości backup'ów. Możliwość integracji z powszechnie stosowanymi systemami backupu. Wykonywanie kopii bezpieczeństwa powinno być możliwe w trybie off-line oraz w trybie online.

— Musi posiadać moduł zarządzania bazą danych przez przeglądarkę WWW

3. System ma zapewnić ewidencję oraz edycję danych opisowych i geometrycznych dotyczących sieci ciepłowniczej oraz innej infrastruktury w postaci warstw zgodnie

z instrukcją K1, G7.

4. System ma wspierać procesy związane z wydawaniem warunków technicznych, uzgodnień terenowych i obsługą służebności.

5. System ma odzwierciedlać zależności topologiczne pomiędzy obiektami infrastruktury ciepłowniczej i zapewniać dużą elastyczność i wierność w modelowaniu istniejących

i projektowaniu nowych obiektów.

3. Platforma systemowa

1. Moduły systemu GIS muszą stanowić jednolite i spójne środowisko systemowe, umożliwiające wykonanie pełnej funkcjonalności w ramach tego środowiska.

2. Protokół komunikacyjny TCP/IP.

3. W przypadku zerwania połączenia sieciowego między serwerem bazy danych,

a aplikacją musi być ono wykrywane i następować ma próba jego automatycznego odtworzenia.

4. System musi umożliwiać tworzenie kopii bezpieczeństwa zarówno w trybie off-line na wyłączonej bazie danych jak i w trybie on-line na pracującej bazie danych.

4. Architektura systemu

1. Architektura modułowa umożliwiająca łatwy i etapowy rozwój systemu.

2. System ma być zbudowany w technologii trójwarstwowej (klient – serwer aplikacji – serwer bazy danych).

3. Architektura całego systemu ma być otwarta (OpenGIS) i zgodna z założeniami OGC (Open Geospatial Consortium).

5. Infrastruktura informatyczna

5.1. Zamawiający oczekuje od Wykonawcy dostarczenia:

5.1.1. Dokumentacji architektury technicznej systemu uwzględniającej wszystkie elementy niezbędne do zapewnienia prawidłowego działania systemu.

5.1.2. Dokumentacji bazy danych, która powinna zawierać specyfikację konfiguracji bazy danych z informacjami o schematach bazy danych, na których są przechowywane dane aplikacji; informacje o przestrzeniach tabel, informacje o istotnych obiektach aplikacji, szczególnie takich jak: linki bazy danych, procedury, pakiety i funkcje; listę kluczowych tabel aplikacji i opis zawartych w nich danych; informacje

o zalecanej konfiguracji backupu i szacowanym rozmiarze bazy danych, opis sposobu wgrywania poprawek na bazę danych, informacje, czy dostawca publikuje listę zalecanych i wspieranych poprawek dla bazy danych; diagram związków tabel używanych przez aplikację; zalecane parametry konfiguracyjne bazy danych; informacje o stronie kodowej, jaką powinna posiadać baza danych; informacje

w jaki sposób powinna być uruchamiana i zatrzymywana aplikacja i baza danych.

5.1.3. Dokumentacji instalacji i konfiguracji dla wszystkich składowych systemu.

5.2. Wykonawca musi zagwarantować, że zaproponowana architektura rozwiązania oraz infrastruktura informatyczna zapewnią spełnienie następujących wymagań:

5.2.1. Zapewnienie efektywnego i bezpiecznego działania systemu.

5.2.2. Zapewnienie dostępności i niezawodności systemu.

5.2.3. Zapewnienie ciągłości działania systemu.

5.2.4. Zapewnienie zabezpieczenia systemu przed przypadkowym lub celowym zniszczeniem danych lub ich modyfikacją.

5.2.5. Zapewnienie zabezpieczenia systemu przed nieuprawnionym dostępem do funkcjonalności lub danych.

5.2.6. Zabezpieczenie danych zgodnie z ustawą o ochronie danych osobowych.

5.2.7. Zapewnienie odpowiedniego środowiska testowego, szkoleniowego

i produkcyjnego.

6. Skalowalność systemu

1. System będzie zarządzał dużymi ilościami danych i zapewniał dostęp do tych danych wielu użytkownikom w tym samym czasie (wielodostęp i współbieżność).

2. System ma być skalowalny, tzn. ma istnieć możliwość rozbudowy systemu wraz ze wzrostem ilości przechowywanych danych lub liczby użytkowników, bez konieczności modyfikacji oprogramowania.

3. Baza danych systemu będzie zarządzała wszelkimi rodzajami danych występującymi w zastosowaniach typu GIS (dane alfanumeryczne, wektorowe, rastrowe, ortofotomapy, zdjęcia lotnicze, inne elektroniczne dokumenty, itp.).

4. System musi posiadać wbudowane mechanizmy wspomagające niezawodność systemu takie jak:

a) wykrywanie przerw w łączności,

b) automatyczne odtwarzanie połączenia,

c) szeroki zakres obsługi i naprawy sytuacji związanych z wystąpieniem błędu.

5. System nie może posiadać ograniczeń co do ilości stanowisk pracy w środowisku www.

W przypadku aplikacji desktop (gruby klient) zakłada się 2 jednoczesnych użytkowników.

6. System powinien być dostępny w trybie ciągłym 24 godz./dobę.

7. Baza danych i aplikacje

1. Oracle 12c Standard Edition One na 1 CPU lub równoważna + serwerowy system operacyjny. Baza danych musi obsługiwać system operacyjny Windows i Linux.

2. Centralna baza danych z możliwością wielostanowiskowego, rozproszonego dostępu (wszystkie dane w jednej centralnej bazie danych).

3. Zastosowana baza ma być zoptymalizowana pod kątem wydajności, w szczególności dla analiz przestrzennych i zarządzania informacją o sieciach. Zastosowane zmiany

w konfiguracji standardowej bazy danych w celu osiągnięcia optymalizacji muszą zostać zawarte w dokumentacji systemu.

4. System ma być oparty na ciągłej bazie geograficznej, która będzie pozwalała na traktowanie całego modelowanego obszaru jak jednej mapy oraz na prezentowanie

w jednolity sposób tak informacji przestrzennej jak i nieposiadającej odniesienia geograficznego, bez podziałów na arkusze map rastrowych czy segmentów bazy. Jest to niezwykle ważne ze względu na specyfikę przedsiębiorstwa, które zarządza sieciami, gdzie pojedynczy przewód czy kanał może przebiegać przez kilka arkuszy mapy.

5. Technika indeksowania przestrzennego ma zapewniać użytkownikom jednakowo dobrą wydajność, niezależnie od liczby równocześnie pracujących stanowisk oraz od rozmiarów bazy danych.

6. Dane mają być traktowane w taki sam sposób niezależnie od ich postaci - rastry, dane wektorowe, dane bez odniesienia przestrzennego.

8. Serwer mapowy WWW

Serwer mapowy powinien spełniać co najmniej wymienione poniżej funkcje:

możliwość publikacji usług internetowych, takich jak mapa, rastry, WMS, WCS, WFS, WFS-T, REST, i SOAP,

zawiera narzędzia do tworzenia rozbudowanych aplikacji mapowych opartych na przeglądarce internetowej,

zawiera narzędzia w postaci komponentów, które można wykorzystać w aplikacjach internetowych (przesuwanie, skalowanie, identyfikacja obiektów, pomiar odległości, wyszukiwanie adresów, zapytania i wyszukiwanie atrybutów, edycję danych wektorowych

i wydruki),

udostępnia otwarty interfejs programistyczny (Application Programming Interface – API),

obsługuje zadania podstawowej edycji danych przestrzennych, takie jak dodawanie, usuwanie i modyfikacja obiektów mapy w zakresie punktów, linii i obiektów powierzchniowych.

Zakłada się instalację serwera mapowego na dedykowanej maszynie fizycznej lub maszynie wirtualnej.

9. Język systemu

Pełna polonizacja systemu w zakresie:

raportów,

ekranów - interfejsu,

komunikatów i podpowiedzi systemowych,

dokumentacji,

obsługi polskich znaków diakrytycznych wraz z sortowaniem zgodnie z polskim alfabetem,

plików pomocy i instrukcji.

10. Bezpieczeństwo danych

1. System musi zapewniać zasadę Single Sign On, to znaczy zalogowany w systemie Windows użytkownik posiadający konto w AD, zostanie automatycznie zalogowany

w systemie GIS, jeśli będzie istniało powiązanie konta użytkownika z AD z kontem

w systemie GIS.

2. Definiowanie uprawnień do funkcji systemu dla każdego użytkownika.

3. Definiowanie uprawnień do funkcji systemu dla grupy użytkowników.

4. Definiowanie uprawnień na poziomie warstw mapy, tablic i pól tablic – poziom dostępu do danych.

5. Zapewnienie kontroli nadanych użytkownikom efektywnych praw dostępu do danych oraz funkcjonalności systemu.

6. Możliwość czasowego przyznania uprawnień.

7. Szeroka kontrola aktywności użytkowników:

a) informacja o logowaniach do systemu,

b) informacja o wprowadzanych zmianach.

11. Backup i archiwizacja danych

1. System musi zapewniać tworzenie backupu off-line i on-line.

2. Oczekiwany czas odtworzenia całego systemu z kopii zapasowej (RTO – ang. Recovery Time Objective) nie może przekroczyć 24 godzin, przy zachowaniu aktualności danych (RPO - ang. Recovery Point Objective) do 24 godzin.

3. Wykonawca dostarczy skrypty oraz dokumentację wykonywania kopii bezpieczeństwa oraz odtwarzania danych dla systemu GIS.

12. Licencjonowanie systemu

1. Zamawiający wymaga licencjonowania dla wszystkich typów stanowisk w trybie dostępu jednoczesnego, bez przypisywania licencji do użytkownika lub komputera.

2. System musi być wyposażony w mechanizm umożliwiający on-line kontrolę i zarządzanie wykorzystanymi licencjami, pozwalający na:

a) podgląd przez kogo i jaka licencja (instancja programu) jest wykorzystana oraz

z jakiego stanowiska i od której godziny,

b) wyłączenie (zabicie) sesji użytkownika,

c) konfigurację dla użytkownika maksymalnej możliwej do uruchomienia ilości instancji danej aplikacji, domyślnie 1 instancja aplikacji dla użytkownika.

3. Oferta ma uwzględniać oprogramowanie dodatkowe niezbędne dla osiągnięcia zakładanej funkcjonalności systemu GIS przy posiadanej przez Zamawiającego infrastrukturze sprzętowo – sieciowo – systemowej.

13. Posiadane dane i migracja

Zamawiający posiada następujące dane:

a) Mapy sieci cieplnej w postaci elektronicznej (pliki PDF,DWG),

b) Mapy sieci w postaci skanów,

c) Mapy sieci w postaci papierowej,

d) Dane dotyczące parametrów urządzeń sieciowych w postaci arkuszy XLS,

e) Dane dotyczące parametrów urządzeń w węzłach cieplnych w postaci arkuszy XLS,

f) Schematy technologiczne węzłów (pliki PDF,DWG),

g) Schematy lokalizacji pomieszczeń węzłów w budynkach (pliki PDF,DWG),

h) Szablony protokołów dotyczące eksploatacji infrastruktury ciepłowniczej (pliki PDF).

14. Platforma sprzętowa

Sprzęt nie stanowi przedmiotu zamówienia.

Zamawiający zapewni Środowisko wg następującej specyfikacji:

Serwer

— Procesor Intel Xeon E5-2603 v2 (2 szt.),

— 32GB RAM,

— Macierz dyskowa typu 0+1 o pojemności 2TB oparta na dyskach SAS,

— Dwie karty sieciowe 10/100/1000,

— Napęd DVD+/-RW,

— Zainstalowany system operacyjny: MS Windows Server 2012R2 64-bit PL.

Stacje robocze dla aplikacji typu „desktop”:

— Dell Vostro V3700 (i5, 8GB RAM, GeForce GT330M),

— Komputer stacjonarny (i5, 8GB RAM, GeForce GT740),

— Zainstalowany system operacyjny: MS Windows 7 Pro 64-bit PL.

15. Model danych

1. Świat w systemie ma być przedstawiany jako zestaw obiektów posiadających charakteryzujące je atrybuty, które są powiązane między sobą stosownymi relacjami.

2. Model powinien być zgodny z wymaganiami:

a) eksploatacji sieci ciepłowniczej,

b) prawa geodezyjnego (instrukcje Geodezyjne K-1 „Mapa Zasadnicza” oraz G-7 „GESUT – Geodezyjna Ewidencja Sieci Uzbrojenia Technicznego").

3. System ma umożliwiać modelowanie relacji jeden-do-jednego, jeden-do-wielu oraz wiele-do-wielu.

4. Atrybuty obiektów mogą być alfanumeryczne (znaki i liczby, jak nazwisko czy numer zlecenia) oraz graficzne (punkty, linie i obszary ze stosowną interpretacją geograficzną).

5. Każdy obiekt powinien posiadać unikalny identyfikator tworzony automatycznie przez system w postaci podanej przez Zamawiającego.

6. Podstawowym poziomem składowania danych będą obiekty takie jak rurociągi, komory, węzły itp. Będą one reprezentować rzeczywiste składniki modelowanego systemu i mogą wchodzić ze sobą we wzajemne relacje.

7. Obiekty posiadające atrybuty geometryczne mogą oddziaływać na poziomie topologicznym. Na przykład przewody mogą łączyć się ze sobą i z komorami.

8. Wszystkie obiekty, które mogą ze sobą oddziaływać mają zostać określone poprzez sieć topologiczną.

16. Typowe rodzaje danych

1. System ma umożliwiać jednoczesne wyświetlanie i korzystanie z podkładu rastrowego oraz

z danych wektorowych. Dzięki temu nie będzie konieczności pełnej digitalizacji wszystkich obiektów rastrowych.

2. Zapis i dostęp do rastrów powinien być zrealizowany w bazie danych.

3. Ciągła budowa bazy danych GIS ma pozwolić na całkowitą integrację danych wektorowych

i rastrowych.

17. Dane geograficzne

1. W modelu danych systemu właściwości geometryczne obiektów mają być reprezentowane przy pomocy punktów, linii i obszarów.

2. Punkty będą reprezentować obiekty wymiaru zero. Każdy punkt będzie miał określone 3 współrzędne.

3. Krzywe to uporządkowane kolekcje odcinków, których będzie używało się do reprezentacji obiektów liniowych, takich jak rzeki, drogi, przewody itd.

4. Obszar to obiekt posiadający powierzchnię, czyli np. działka, budynek, terytorium miasta itp.

5. Ważną cechą modelu danych systemu ma być posiadanie przez obiekty bazy danych zdefiniowanych przez użytkownika wielu cech geometrycznych np. budynek może posiadać obrys fundamentów i obrys konstrukcji zewnętrznej.

6. Każdy obiekt w systemie GIS może posiadać nieograniczoną ilość opisujących go cech/atrybutów możliwych do samodzielnego definiowania przez administratora.

7. Do każdego obiektu w systemie GIS istnieje możliwość dodania dowolnej ilości załączników w dowolnym formacie.

8. Geometria obiektu nie musi być elementem obowiązkowym. System musi umożliwiać utworzenie obiektów bez geometrii i dodanie jej do już utworzonego obiektu w dowolnym innym czasie edycji danych obiektu. Przykładowo: jeśli dokładne umiejscowienie na mapie zgłoszonej awarii nie jest jeszcze znane, można utworzyć obiekt awaria z opisem (m.in. lokalizacji), natomiast zaznaczenie na mapie dodać po dokładniejszym ustaleniu miejsca. Warstwa w GIS musi posiadać atrybuty opisowe i geometrię w jednej tablicy, a geometria musi być zapisana w postaci typu przestrzennego SDO_GEOMETRY opcji Oracle Locator lub równoważny w przypadku innej bazy danych.

18. Dane alfanumeryczne i numeryczne (słowniki)

1. Słowniki mają być zastosowane do opisu wielkości nienumerycznych i numerycznych

o ograniczonej licznie dopuszczalnych wartości, takich jak np. nazwy stanów urządzenia („w użyciu", „odłączony", „w remoncie” itp.).

2. Zastosowanie słowników ma pozwolić na kontrolowanie poprawności wprowadzanej przez użytkowników wartości.

3. System musi umożliwiać samodzielne modyfikowanie i uzupełnianie wszystkich dostępnych słowników.

4. System musi umożliwiać wykorzystanie danego słownika do opisu atrybutów dla różnych typów obiektów.

19. Topologia sieci

1. System ma automatycznie utrzymywać i uaktualniać powiązania topologiczne na podstawie reguł określanych w czasie tworzenia modelu danych.

2. Reguły topologiczne mają określić, czy i jak dana para obiektów ze sobą oddziałuje. Na przykład: armatura dzieli sieć na dwa odcinki; dwa odcinki sieci przecinając się nie oddziałują na siebie

(w przypadku przechodzenia przewodów jeden nad drugim), ale już dwa przewody stykające się końcami można uznać za połączone itd.

3. Wszystkie te zależności muszą zostać określone na podstawie reguł, które powinny być zaimplementowane w systemie.

4. Topologia powinna być automatycznie tworzona/modyfikowana podczas wprowadzania /modyfikowania obiektów w bazie danych.

5. W wyniku modyfikacji zawartości bazy danych może nastąpić podział istniejących obiektów, wstawienie nowych węzłów lub (w przypadku braku oddziaływania) zmiany powinny zakończyć się na dodaniu nowego obiektu.

6. Reguły topologiczne mają również być wykorzystywane do wykrywania kolizji nowych obiektów z istniejącymi, na przykład do wykrywania tych miejsc, w których projektowany przewód wodociągowy, kanalizacyjny bądź energetyczny przecina się z istniejącymi instalacjami innego rodzaju.

7. W przypadku istnienia standardowych metod rozwiązywania takich kolizji należy stworzyć ich katalog (szablony protokołów odbioru kolizji z poszczególnymi dysponentami obcej infrastruktury liniowej), który będzie wykorzystywany w takich przypadkach bez potrzeby wymyślania na nowo znanych rozwiązań.

8. Topologia sieci musi uwzględniać stan obiektu i wizualizować obraz sieci w odpowiedzi odpowiednio zgodnie ze zdefiniowanymi regułami (np. stan zaworu: otwarty/ zamknięty: innym kolorem, inną ikoną).

9. Wszystkie reguły edycyjne/topologiczne powinny być zaimplementowane na poziomie bazy danych.

20. Wymiana danych

1. System ma zapewniać szerokie możliwości wymiany danych z innymi systemami informatycznymi.

2. Poza oferowanymi standardowymi metodami konwersji danych istotne będą również narzędzia, które pozwolą na korzystanie z danych przechowywanych w innych formatach bez konieczności wykonywania trwałej translacji (przeniesienia). Funkcjonalność ta może być zapewniona przez zapewnienie odpowiednich modułów stanowiskom typu desktop.

3. Możliwość eksportu i importu (wymiany) danych do/z systemów w różnych formatach,

a co najmniej shp, .txt, .html, .xls ,.xml, dwg, dxf.

4. System musi współpracować z oprogramowaniem biurowym (MS Office, OpenOffice) oraz posiadać możliwość komunikacji z różnymi bazami danych oraz łatwość budowy interfejsów.

5. System musi posiadać możliwość importu danych ewidencyjnych w formacie SWDE.

6. System musi posiadać interfejs pozwalający na podłączenie się do zewnętrznych serwerów WMS w celu pobrania danych i wyświetlenia ich jako osobnych warstw

w systemie.

7. Możliwość zaimportowania pliku tekstowego ze współrzędnymi pikiet wysokościowych.

21. Dostęp do obcych plików on-line

1. System musi umożliwiać wyświetlanie szerokiej gamy formatów danych geograficznych bez konieczności dokonywania konwersji tych danych do wewnętrznego formatu systemu.

2. Mechanizm taki musi umożliwiać obsługę co najmniej kilku następujących formatów danych:

c) Autodesk – DWG,

d) Autodesk – DXF,

e) Bentley – DGN,

f) ESRI – SHP,

g) TIFF - Tagged Image File Format,

h) BMP - Windows Bitmap,

i) JPEG - Joint Photographic Experts Group.

22. Komunikacja z zewnętrznymi bazami danych

1. System powinien zapewniać możliwość wymiany danych on-line oraz off-line z dowolnymi bazami danych zarówno „serwerowymi” jak i „plikowymi” przy pomocy własnych mechanizmów lub driverów ODBC, bazy danych mogą być relacyjne i nierelacyjne (płaskie, obiektowe) (szczególnie dla Oracle, MS-SQL, Access, DBF, Tekst, XML, Excel).

2. System powinien zapewniać możliwość wymiany danych on-line przez mechanizmy systemu, interfejsy lub mechanizmy uniwersalne (ODBC) z systemami opartymi

o relacyjne bazy danych.

23. Interfejs użytkownika

1. System musi umożliwiać pełne dostosowywanie interfejsu tzn. usuwanie/dodawanie /grupowanie pól ekranowych, zmianę ich wymagalności, etykiet, kolejności na ekranie

i układu ekranu, dodawanie i usuwanie zakładek, możliwość wyszukiwania informacji wg dowolnie wybranych pól opisowych bez znajomości języka programowania.

2. System ma umożliwiać, przy wykorzystaniu odpowiednich narzędzi, dostosowanie aplikacji

w sposób umożliwiający zwiększanie funkcjonalności systemu i tworzenie innych wyspecjalizowanych (szytych na miarę) stanowisk przez pracowników przedsiębiorstwa bez konieczności ingerencji dostawcy systemu.

3. Przy pomocy stosownych mechanizmów zaoferowanych przez system musi istnieć możliwość zdefiniowania wszystkich obiektów w systemie, rodzajów relacji pomiędzy nimi, reguł topologicznych sieci i innych, bez konieczności pisania kodu (programowania).

4. System ma bazować na graficznym, okienkowym interfejsie użytkownika.

5. Dostęp do odpowiednich funkcji menu ma być uwarunkowany poprzez przypisane uprawnienia dla użytkownika lub grupy użytkowników.

6. Użytkownik ma mieć możliwość definiowania i zapamiętywania na stałe wyglądu

i zawartości interfejsu.

7. Administrator ma mieć możliwość definiowania, zapamiętywania i przypisywania na stałe wyglądu i zawartości interfejsu dla wybranego użytkownika, grupy użytkowników lub wszystkich.

24. Biblioteki symboli

1. System stylów systemu ma umożliwiać uprawnionemu użytkownikowi całkowitą kontrolę nad reprezentacją graficzną dowolnych obiektów na mapie branżowej.

2. Obiekty liniowe, takie jak odcinki sieci ciepłowniczej, przedstawiane są liniami, którym można nadać dowolny kolor, grubość i wzór.

3. Obiekty obszarowe, takie jak np. miasto, mogą mieć własny kolor, wzór granicy oraz wzór wypełniający.

4. Symbole przechowywane mają być w bibliotekach symboli dostępnych dla wszystkich uprawnionych użytkowników.

5. Jeśli symbol ulegnie zmianie, to musi zmienić się jego reprezentacja graficzna we wszystkich aplikacjach wchodzących w skład systemu GIS używających tego symbolu.

6. System ma umożliwiać dostosowywanie się prezentacji graficznej i jej symboli

w zależności od skali prezentacji (definiowanie, co ma się pojawiać na mapach w danej skali) – każdy użytkownik może posiadać własne ustawienia.

7. Dla mapy zasadniczej symbolika elementów ma być zgodna z instrukcją geodezyjną K-1 „Zasadnicza mapa kraju".

8. O ile to możliwe symbolika mapy branżowej ma być zgodna z instrukcją geodezyjną

K-1 oraz G-7.

25. Zapytania ad-hoc

1. Standardową funkcją systemu ma być wspomaganie tworzenia szybkich zapytań, które mogą dotyczyć także atrybutów przestrzennych lub powiązań między obiektami.

2. Narzędzia dostarczone wraz z systemem mają być jak najbardziej ogólne i pozwalać operatorowi na wprowadzanie dowolnej kombinacji zadawanych pytań.

3. Będzie musiała być zapewniona możliwość zaprogramowania tych zapytań, których wyniki będą często wykorzystywane w pracy służb przedsiębiorstwa tak, aby tworzenie raportów wymagało jak najmniejszego wysiłku ze strony użytkownika systemu.

4. System przy tworzeniu zapytań geograficznych ma opierać się na okienkach

z podpowiedziami (kreator).

5. Użytkownik będzie wybierał kolejne pozycje z przedstawianych mu list i odpowiadał na pytania, których ostatecznym wynikiem ma być zapytanie zadawane bazie danych.

6. Język używany w zapytaniach ma stanowić rozszerzenie składni SQL o możliwości tworzenia zapytań przestrzennych, rozstrzygających takie zależności przestrzenne jak zawieranie się, przyleganie, przecinanie, nakładanie, stykanie itp.

7. Gotowe zapytania oraz ich wyniki będzie można zapisywać do późniejszego wykorzystania.

8. Poza tworzeniem zapytań z ww. poziomu, musi istnieć możliwość wpisywania wprost tekstu zapytania w języku SQL.

9. Wyniki zapytań mogą być wyświetlane na mapie, przesyłane do generatora raportów, przekazywane innym aplikacjom lub zachowane do użycia w przyszłości.

26. Rastry

1. System musi dostarczyć narzędzia służące do konwersji danych graficznych, zarówno rastrowych jak i wektorowych.

2. Obsługa co najmniej georeferencyjnych danych rastrowych w formacie TIFF i CIT.

3. Możliwość importu map rastrowych bez georeferencji i samodzielne nadawanie jej

w programie

4. Poza monochromatycznymi mapami rastrowymi system musi również wykorzystywać rastry kolorowe oraz zdjęcia lotnicze.

27. Wektor

1. System poza obsługą formatu wektorowego SHP musi umożliwiać import danych

z formatów używanych przez inne systemy oprogramowania (co najmniej DWG, DXF, DGN).

2. System ma zapewniać tzw. konwertery do zewnętrznych formatów: DXF, SHP, TXT, XLS, MDB.

28. Układy współrzędnych

1. System ma pracować w układzie współrzędnych 2000.

2. System ma obsługiwać wiele różnych systemów projekcji mapy (układów współrzędnych).

3. System ma mieć możliwość korzystania dodatkowo co najmniej z następujących układów współrzędnych:

i) 1992,

j) 1965,

k) WGS84 geograficznych: Dł., Wys., Szer.

4. Mają być dostępne co najmniej następujące funkcje systemu:

a) możliwość dokonywania konwersji pomiędzy różnymi układami współrzędnych,

w tym konwersji w locie,

b) możliwość eksportu i importu danych w układzie współrzędnych innym niż użyty

w bazie danych GIS,

c) podawanie współrzędnych punktów w innych układach współrzędnych niż użyty

w bazie danych,

d) wyświetlanie treści mapy w dowolnie wybranym (spośród zdefiniowanych) układzie współrzędnych.

29. Wybór treści – wyszukiwanie obiektów

1. System ma zapewniać szerokie możliwości wyboru zawartości przeglądanych danych takie jak chociażby:

a) Dające się dostosować skalowanie widoku z automatycznym wyborem rodzajów

i wyglądu obiektów, które będą widoczne w predefiniowanych przedziałach skali. Pozwoli to na uniknięcie zbyt dużego zagęszczenia obiektów wyświetlanych zwłaszcza w małej skali (przy dużym oddaleniu).

b) Przesuwanie ze stosowaniem rozmaitych kryteriów (płynne, do wskazanego punktu, wzdłuż definiowanego obiektu, itp.) oparte na założeniach DDC (Dynamic Display Cache) lub innej równoważnej technologii.

c) Generowanie map tematycznych – na podstawie dostępnych danych można wygenerować nową tablicę, a graficzną reprezentację jej zawartości przedstawić na mapie i/lub wydruku.

d) Obiekty z bazy danych będzie można wybierać bezpośrednio z mapy lub wyszukiwać przy pomocy dostępnych w systemie narzędzi. Będzie można przy tym korzystać z języka zapytań opartego na języku SQL i uzupełnionego o możliwości wykonywania zapytań przestrzennych.

2. System ma umożliwiać tworzenie własnych zapytań przy użyciu menu, tablic itp., co wyeliminuje konieczność uczenia się nowych składni.

3. Wyniki wyszukiwania wśród danych alfanumerycznych będzie można przedstawić na mapie w postaci graficznej.

4. Zapytania przestrzenne mają mieć możliwość zagnieżdżania wyniku jednego zapytania dla przygotowania drugiego zapytania opartego o uzyskany wynik.

5. Można również wybierać obiekty z mapy, odczytując ich atrybuty niegeometryczne oraz informacje o obiektach związanych w jakiś sposób z danym obiektem.

30. Analizy sieciowe

1. System ma zapewniać wiele funkcji do wykonywania analiz przestrzennych i sieciowych.

2. Podstawowe moduły do analiz sieciowych mają pozwalać m.in na:

a) prezentację obszaru pozbawionego dostaw ciepła, wyniku awarii lub zamknięcia zasuw,

b) znajdowanie źródeł zasilania dla węzła,

c) znajdowanie fragmentu sieci spełniającego podane kryteria (np.: te fragmenty sieci

o zadanej średnicy, które znajdują się w określonej odległości od punktu wskazanego jako początkowy),

d) odpowiednią prezentację graficzną wyników zapytań.

3. Możliwie jak najszerzej rozumiana złożoności kryteriów dla przeprowadzanych analiz.

4. Musi istnieć możliwość wykonania śledzenia sieci, które wykorzysta funkcję kosztu (na przykład śledzenie wzdłuż projektowanej trasy przewodu, które określi koszt jego budowy).

5. Znalezione fragmenty sieci będzie można również wyświetlić w głównym oknie aplikacji na tle pozostałych danych z odpowiednim ich rozróżnieniem (np. pogrubienie, podświetlenie, inny kolor).

6. Standardowe funkcje systemu mają pozwalać na lokalizację dowolnego obiektu przy pomocy kombinacji jego atrybutów.

7. Zapytania tego typu mają używać między innymi funkcji śledzących i przestrzennych, dzięki czemu nie trzeba przechowywać w jawnej postaci danych o powiązaniach. Np. można znaleźć punkt zasilający, do którego przyłączony jest (pośrednio) klient

o wskazanym adresie wykonując śledzenie trasy od tego adresu i wskazując pierwszy znaleziony punkt zasilający. Nie trzeba nigdzie zapisywać, którzy klienci są podłączeni, do którego źródła należą.

31. Tworzenie raportów

1. System musi posiadać generator raportów pozwalający na tworzenie szablonów raportów, które następnie będzie można zapisać i wykorzystywać np. w późniejszym czasie. Generator raportów może być oddzielną aplikacją, lecz nie może posiadać limitu co do ilości użytkowników.

2. Tworzenie raportów powinno polegać na wygenerowaniu sformatowanego raportu używając do tego celu wskazanego szablonu i wskazanych danych.

3. Musi istnieć możliwość wykorzystania do raportu danych uzyskanych w wyniku wykonanego wcześniej śledzenia, zapytania lub analizy.

4. Raporty będą mogły zawierać dowolne kombinacje pól wybranych rekordów wraz

z pozycjami specjalnymi (takimi jak sumy czy średnie) oraz dowolne dane pochodzące z systemu.

5. Raporty będzie można zapisywać do pliku na dysku twardym (ta sama funkcjonalność dla zbiorów obiektów otrzymanych w wyniku zapytań).

6. Musi istnieć możliwość eksportu danych z raportów do edytorów tekstu lub arkuszy kalkulacyjnych.

7. Narzędzie do tworzenia raportów nie może posiadać ograniczenia co do ilości użytkowników z niego korzystających.

8. Aplikacja WWW i aplikacja desktop musi umieć odczytywać ten sam szablon raportu w obu aplikacjach. Raz utworzony szablon będzie prezentował dane identycznie

w dowolnej aplikacji.

32. Drukowanie i plotowanie

1. System ma drukować wszelkie dane w nim zgromadzone oraz dane importowane do GIS

z innych systemów.

2. Użytkownik musi mieć możliwość podjęcia decyzji, które z obiektów przedstawione na mapie GIS znajdą się na wydruku.

3. Menadżer wydruków ma umożliwiać dokładanie do wydruków adnotacji i symboli oraz umożliwiać umieszczenie na wydruku dowolnych obrazów z zewnętrznych plików.

4. Drukowanie ma odbywać się w formatach odpowiednich dla drukarek i ploterów znajdujących się obecnie na rynku (co najmniej w zakresie od A4 do A0) z możliwością definiowania własnych rozmiarów.

5. Standardowym elementem menadżera wydruków ma być narzędzie do oglądania planowanych wydruków pozwalające operatorowi na przyjrzenie się wydrukowi w takiej postaci, w jakiej trafi on do drukarki lub plotera, z uwzględnieniem wzorca ramki, adnotacji, symboliki.

6. System powinien posiadać możliwość drukowania obiektu na oddzielnych arkuszach z zakładką.

33. Aplikacja Desktop GIS:

Należy dostarczyć 2 licencje jednoczesnego użytku aplikacji desktop GIS.

Wykaz podstawowych funkcjonalności dla aplikacji Desktop GIS:

legenda mapy: dokowana do okna programu, grupowanie warstw w legendzie mapy, menu podręczne legendy na prawym przycisku myszy, ustawianie właściwości warstw po wybraniu pozycji na legendzie, powiększenie mapy do bieżącej warstwy, prezentacja metadanych warstwy (zasięg, źródło danych),

narzędzia nawigacji po mapie: cała mapa, pomniejszanie, powiększanie, panoramowanie (przesuwanie mapy), przejście do punktu o zadanych współrzędnych, okno nawigacji, przejście do obszaru roboczego,

dodawanie do mapy warstwy z pikietami wysokościowymi, których współrzędne Z wykorzystywane są przez system w trakcie rysowania sieci (system ma podpowiadać współrzędną Z obiektu jako współrzędną Z najbliższej pikiety)

konfigurowanie dynamicznych opisów (tooltip dla dowolnego obiektu),

tworzenie obszarów roboczych, filtracja mapy wg obszarów,

identyfikacja obiektów na mapie z możliwością przejścia do edycji elementu,

edycja obiektów dowolnej edytowalnej warstwy, przejście do wstawiania geometrii,

pomiar odległości i pomiar powierzchni,

wyszukiwanie i selekcja danych wg geometrii, szybkie narzędzia selekcji z menu głównego (wewnątrz prostokąta, wieloboku, wokół punktu, cały ekran), kasowanie bieżącej selekcji,

wyszukiwanie i selekcja wg atrybutów opisowych,

funkcje sieciowe i nadawanie miar (szukanie punktu o zadanej mierze w trasie, wskazywanie miary dla zadanego punktu).

dodawanie własnych atrybutów obiektów,

dodawanie atrybutów będących wynikiem obliczeń na podstawie innych atrybutów obiektu

tworzenie nowych warstw shapefile i warstw bazodanowych, wykorzystanie istniejących warstw jako wzorców,

pasek narzędzi edycyjnych konfigurowanych przez użytkownika,

statystyka na warstwach, statystyka na tablicach opisowych, tworzenie wykresów, zapamiętywanie konfiguracji,

menu główne oraz konfigurowalne menu dla danych opisowych, formatka typu drzewo nawigacji,

menu podręczne na prawym przycisku myszy na mapie w tym funkcje: pomniejszanie, powiększanie identyfikacja, edycja obiektu na bieżącej warstwie, wyszukanie i wybór innych edytowalnych obiektów na mapie w pobliżu,

wielofunkcyjna formatka z danymi opisowymi: w tym podział danych na zakładki, geometria jako jedna z zakładek, prezentacja i edycja danych z tablic podrzędnych na zakładce,

funkcje nawigacji po danych w rekordach, przejście do rekordu o zadanym numerze, podświetlanie obiektu, podświetlanie poprzedniego kształtu obiektu, wyróżnianie kolorem, panoramowanie do obiektu (przesuwanie), powiększanie do obiektu,

funkcje wstawiania, wycofania zmian, zapisu, odświeżania, usuwania danych, zapis wszystkich zmian w zbiorze rekordów, usunięcie wszystkich rekordów,

filtracja danych na formatce, filtrowanie tylko spośród już wybranych danych, filtracja dla pojedynczych dat, przedziałów dat,

funkcja kolorowania wierszy w widoku zbiorczym w zależności od parametru np. wartości w kolumnie, kolorowanie pól na formularzu w zależności od parametru np. wartości przekroczenia,

selekcja wszystkich obiektów na mapie z formatki, selekcja tylko bieżącego rekordu, operacje na zbiorze selekcji (nowy, dodawanie, odejmowanie),

listy wyboru, w tym listy z danymi multimedialnymi, stale widoczne przyciski list,

data wprowadzana z kalendarza lub ręcznie, wybieranie z mapy zamiast listy

z ograniczeniami przestrzennymi, autouzupełnianie jeśli tylko jedna pozycja na liście,

widok zbiorczy danych, sortowanie danych, eksport do html, lista z danymi hierarchicznymi (typu master – detail), możliwość eksportu do Excela (XLS,XLSX),

edycja danych geometrycznych przez menu kontekstowe na mapie,

edycja geometrii przez dociąganie do wielu warstw jednocześnie, priorytet konfigurowalny – decyduje kolejność, każda pozycja dociągania ma indywidualne właściwości,

narzędzia edycji geometrii: rozdwajanie linii, generalizacja linii, odwracanie kierunku linii (wraz z przepisaniem/zachowaniem atrybutów),

narzędzia domiarowania – dokładne wyznaczanie punktów i pomocniczych kresek domiarowych, zapis domiarów do warstw,

import danych z pliku tekstowego do warstw z możliwym dowolnym układem kolumn

w pliku,

eksport widoku mapy z georeferencjami do bmp, eksport do JPG, ustawianie parametrów eksportu i jakości obrazu,

podgląd wydruku, ustawienia wydruku, rozbudowane adnotacje, wydruk do pliku (zamiast do drukarki), wydruk do EMF – wektorowy obraz o jakości wydruku,

pomoc ogólna, pomoc kontekstowa (związana z bieżącą formatką), możliwość tworzenia pomocy branżowej – kontekst wynika z bieżącego rodzaju danych na formatce opisowej,

Interfejs oraz system pomocy w języku polskim.

Aplikacja desktop GIS musi posiadać narzędzia do szybkiej edycji topologicznej posiadające funkcje:

grupowego dzielenia odcinków sieci w węzłach (selekcja węzłów na mapie, które podzielą sieć),

grupowego dociągania węzłów do sieci (selekcja węzłów, które zostaną grupowo dociągnięte),

grupowego dociągania węzłów i dzielenia sieci (selekcja węzłów, które zostaną grupowo dociągnięte i sieć zostanie automatycznie podzielona).

Narzędzie musi posiadać konfigurator, w którym będzie można podać promień dociągania węzłów do sieci oraz będzie można określić, jakie węzły mogą dzielić jaką sieć. Konfiguracja musi być zapamiętana jako dedykowane przyciski dla użytkownika. Użytkownik sam wybiera ikonkę przycisku.

Narzędzia do zaawansowanej edycji topologicznej muszą posiadać funkcje:

konfiguracji relacji pomiędzy obiektami sieci i węzłów w zakresie określenia czy węzeł ma dzielić sieć, czy tylko ma się dociągać, konfiguracji wykluczeń jakie węzły nie mogą dzielić sieci i nie mogą się dociągnąć, konfiguracji dedykowanych przełączników umożliwiających wybieranie atrybutów jako ikonek podczas edycji geometrii, użytkownik sam może zdefiniować, jaki atrybut zdefiniuje za pomocą przełącznika oraz może sam określić ikonkę przełącznika, podczas edycji użytkownik może zmienić przełącznik tym samym zmieniając atrybut, przełączników może być dowolna ilość dla dowolnej liczby atrybutów,

konfiguracji zachowań się obiektów podczas podziału sieci lub scalania sieci

z określeniem, jakie atrybuty system ma przepisywać podczas podziału i jakie atrybuty ma uzgadniać podczas scalania sieci o różnych parametrach, wartość przepisywana może być z dzielonego obiektu lub może posiadać określony stały parametr.

Podczas scalania sieci system ma się zapytać jakie atrybuty należy przyjąć w przypadku różnych wartości.

Wszystkie konfiguracje muszą być wykonywane z poziomu interfejsu użytkownika

i zapisywane w jego ustawieniach lub w bazie danych. Konfigurację można odczytać z bazy danych. Dowolny użytkownik będzie mógł odczytać konfigurację z bazy danych od innego użytkownika.

Podczas edycji topologicznej można podać długość edytowanego odcinka, kąt następnego segmentu.

System po wprowadzeniu odcinka musi automatycznie zaproponować, jaki węzeł należy wstawić na końcu odcinka. Wybrany węzeł musi posiadać przełączniki z typami węzła lub atrybutami np. przełącznik określający średnicę studzienki, użytkownik zaznacza tylko ikonkę średnicy DN1000 bez wpisywania z klawiatury tych wartości. Po wprowadzeniu węzła następuje kontynuacja rysowania sieci od wprowadzonego węzła bez konieczności zamykania okna edycyjnego. Użytkownik za pomocą 1 formularza edycji topologicznej będzie mógł edytować cały ciąg obiektów punktowo - liniowych, które wcześniej skonfigurował

w konfiguratorze topologii.

Modyfikacja sieci lub węzła spowoduje modyfikację obiektów dociągniętych, przesunięcie węzła spowoduje przesunięcie sieci.

Użytkownik podczas edycji topologicznej na formularzu edycji może zmieniać promień dociągania lub wyłączyć dociąganie, jeżeli będzie taka potrzeba.

MODUŁY BIZNESOWE

34. Wspomaganie wydawania warunków technicznych – WT (przeglądarka WWW)

Moduł WT będzie wspierał proces wydawania warunków technicznych od złożenia wniosku do wydania pisma do klienta.

Moduł WT musi posiadać następujące funkcjonalności:

rejestracja klientów (osoby fizyczne, prawne),

możliwość importu danych klienta z innego systemu informatycznego (np. systemu ERP) lub powiązanie danych wprowadzonego w systemie GIS klienta z klientem systemu ERP

i wyświetlanie danych z systemu ERP w formatce oprogramowania GIS (wg wcześniej ustalonego schematu),

rejestracja wniosków (opracowania warunków technicznych),

rejestracja skanu planu sytuacyjnego,

rejestracja statusu wniosku:

wniosek przyjęty,

wniosek odrzucony,

wniosek zarejestrowany,

historia statusów wniosków,

lista wniosków WT do realizacji,

opracowanie Warunków Technicznych,

statusy WT:

— opracowywanie Warunków Technicznych,

— warunki gotowe do zatwierdzenia,

— warunki zatwierdzone,

— warunki odrzucone,

wnioski WT, opracowania – widok zbiorczy,

wydawanie pism dokumentów WT,

projektowanie warstw wraz z szacunkowym nakładem,

wydruk planu sytuacyjnego,

dostęp do danych miejskich i branżowych,

konfigurowalne szablony dokumentów treści pism.

35. Wspomaganie obsługi uzgodnień lokalizacyjnych – UL (przeglądarka WWW)

Moduł UL będzie wspierał proces obsługi uzgodnień lokalizacyjnych od złożenia wniosku do wydania pisma do klienta.

Moduł UL musi posiadać następujące funkcjonalności:

rejestracja klientów (osoby fizyczne, prawne).

możliwość importu danych klienta z innego systemu informatycznego (np. systemu ERP) lub powiązanie danych wprowadzonego w systemie GIS klienta z klientem systemu ERP

i wyświetlanie danych z systemu ERP w formatce oprogramowania GIS (wg wcześniej ustalonego schematu),

rejestracja wniosków (o uzgodnienie kolizji).

rejestracja statusu wniosku:

— wnioski przyjęte (w fazie rejestrowania),

— wnioski z wyznaczonym obszarem uzgodnienia (w fazie rejestrowania),

— wnioski zarejestrowane,

wydruk rejestru wniosków,

przestrzenna rejestracja obszarów uzgodnień,

rejestracja wydawanych uzgodnień,

automatyczne przeszukiwanie warstw branżowych celem wyszukania obiektów kolidującym

z obszarem uzgodnienia,

identyfikacja statusu uzgodnienia:

— przyjęty do ewidencji uzgodnień,

— określono status kolizji,

— dokumenty wydane klientowi,

— dokumenty przekazane do MPEC,

wydawanie pism-odpowiedzi (kolizja, brak kolizji), uwagi,

wydruk rejestru uzgodnień,

dostęp do danych miejskich i branżowych,

sprawozdania okresowe z wydanych uzgodnień,

konfigurowalne treści pism.

36. Wspomaganie obsługi służebności –OS (przeglądarka WWW)

Program musi umożliwiać rejestrowanie spraw związanych z wnioskami o ustanowienie służebności oraz musi wspomagać w wyliczeniu wysokości służebności na podstawie analiz położenia obiektów sieci ciepłowniczej na działkach.

Moduł OS musi posiadać następujące funkcjonalności:

Obsługa przez przeglądarkę internetową.

Rejestracja nowych spraw o ustanowienie służebności, nadawanie i zmiany statusu sprawy.

Oznaczanie informacji wymaganych dla nowej sprawy.

Ewidencja klientów.

Wybór klienta dla sprawy z ewidencji klientów.

Możliwość wyszukania klienta po dowolnych jego parametrach.

Rejestracja działek dotyczących sprawy.

Podczas wprowadzania danych działki system umożliwi wybór z listy lub wpisanie ręcznie pełnego numeru działki oraz w przypadku pozostawienia niewypełnionych atrybutów zostaną one wypełnione informacjami pobranym z działki z systemu GIS

(o ile takie informacje istnieją).

Aplikacja umożliwi wprowadzenie ilości sieci na działce oraz powierzchni komór, a także system pobierze dane pochodzące z analizy sieci na działkach (długości sieci na działce, powierzchnia komór).

System wyliczy powierzchnię pasa pod siecią ciepłownicza oraz wartość służebności.

System umożliwi dodawanie dowolnych dokumentów do sprawy.

Wyszukiwanie i prezentacja obiektów sieciowych położonych w granicach danej nieruchomości/działki.

System umożliwi wizualizację na mapie różnych statusów spraw.

System potrafi wyznaczyć listę działek o nieuregulowanej służebności na których zlokalizowane są obiekty sieciowe objęte inwestycją lub obiekty planowanej sieci.

37. Integracja z obecnie posiadanymi systemami – ERP – Środki Trwałe

1. System GIS na podstawie przypisanego do danego obiektu numeru ewidencyjnego środka trwałego będzie pokazywał informacje zgromadzone o nim w systemie ERP:

a) wartość,

b) amortyzacja,

c) opis ŚT,

d) klasyfikacja ŚT,

e) osoba odpowiedzialna.

2. Wykonawca utworzy warstwę amortyzacji, w której obiekty będą wyświetlane w kolorach odpowiadających zakresowi stopnia amortyzacji. Kolor dla danego stopnia amortyzacji będzie definiowany przez Zamawiającego.

3. System będzie w stanie wygenerować mapę z zaznaczonymi obiektami wskazanego typu/typów, które nie są powiązane z żadnym środkiem trwałym.

4. System będzie generował definiowalne raporty uwzględniające m.in. stopień amortyzacji obiektów lub braku przypisania obiektu do środka trwałego.

5. Przypisanie/powiązanie środka trwałego z obiektami w GIS wykona Zamawiający.

6. Informacje o środkach trwałych pobierane będą za pomocą integracji z systemem ERP. Nie przewiduje się przekazywania danych do systemu środków trwałych z systemu GIS.

7. Niezbędne dane potrzebne do integracji wystawione zostaną z systemu ERP. Koszty udostępniania tych danych poniesie Zamawiający.

38. Sieci alarmowe

1. Zarządzanie elementami sieci alarmowej: Obwód alarmowy, Alarm, Detektor, Moduł komunikacyjny, Element sieci alarmowej, wraz ze słownikami rodzajów i typów.

2. Możliwość wprowadzania Alarmów, które wystąpiły na sieci (wraz z pozycją na mapie). Dla każdego alarmu definiowany jest status obsługi oraz czasy zgłoszenia i rozwiązania problemu.

3. Podświetlanie na mapie w różnych kolorach odcinków należących do obwodów alarmowych.

II. Oprogramowanie GIS przeznaczone jest do zadania współfinansowanego ze środków Unii Europejskiej w

ramach Programu Operacyjnego Infrastruktura i Środowisko, oś priorytetowa 9 "Infrastruktura Energetyczna

Przyjazna Środowisku i Efektywność Energetyczna", działanie 9.2 „Efektywna dystrybucja energii”, projekt pn.

„Ograniczenie strat i poprawa pewności dostaw ciepła poprzez modernizację sieci ciepłowniczej w Tarnowie”.

III. Oferty równoważne:

III.I. Ilekroć w opisie przedmiotu zamówienia wskazane zostały normy, aprobaty, specyfikacje techniczne,

systemy odniesienia, producent, typ itp. Zamawiający dopuszcza rozwiązania równoważne opisywanym.

III. II. Za ofertę równoważną uznana zostanie ta oferta, która zawierać będzie przedmiot zamówienia o

parametrach co najmniej takich samych bądź bardziej korzystnych

w stosunku do parametrów, które podane są w opisie przedmiotu zamówienia.

III.III. Na Wykonawcy spoczywa ciężar dowiedzenia równoważności oferty poprzez załączenie do niej

odpowiednich dokumentów potwierdzających równoważność

IV.IV. W przypadku złożenia przez Wykonawcę oferty równoważnej, Zamawiający przed ostatecznym

zakwalifikowaniem oferty do dalszego udziału w postępowaniu podda ją ocenie pod kątem spełnienia wymogu,

o którym mowa w pkt. III.II.

IV.3.4) Termin składania ofert lub wniosków o dopuszczenie do udziału w postępowaniu:

3.6.2015 (10:30)

IV.3.7) Warunki otwarcia ofert:

3.6.2015 (11:15)

Dyrektywa 2004/17/WE