当 GIS の構築スケジュール 関連箇所 当 GIS と連携する庁内他 GIS もこの時期に改修終了予定 意見 連携要件で考慮した提案が必要と考えられる為, 具体的にはどのような GIS を指しているのか提示して頂けないでしょうか 具体的なシステム名は明示できませんが, 次のとおり,

Transcription

1 神戸市市民公開型 GIS 構築 運用業務に関する意見書 資料名頁番号 / 項目等確認内容等回答 貴市の市民公開型 GIS 構築にあたっては, 政令指定都市のASP 方式による市条件として 日本国内で1 年間以上稼働している官公庁用 GIS( 地理情報シ民公開型 GIS 導入実績があり, 現在,1つ以上の自治体において稼働中であるこステム )( 当調達で導入予定のGISとは別の製品でも可 ) を提供した経験と が条件として必須ではないかと考えますが如何でしょうか? をもつ者, 若しくはこれと同等の能力と当市が認める実績をもつ者 で当市の要求を実現可能と考えます 1 入札説明書 3 第 2 競争入札参加資格に関する事入札参加資格に関する事項の変更はいたしません 2 落札者決定基準 1 2 総合評価の方法 神戸市様の総合評価の方法は価格点と技術点が 5:5 の割合となっておりますが, 神戸市様の要求仕様を限りなく実現しようと思った場合, 価格も比例して上がってしまいます 安かろう悪かろう という提案をした企業が特定されるのは神戸市様としても望むところではないと思われ, 価格点と技術点の比率を 3:7 程度にすることを検討いただけないでしょうか? 仕様の実現性, 価格を総合して評価するための割合を 1:1 としています 落札者決定基準の変更はいたしません 3 提案書の記載方法等 1 項番 :2 大項目 :1 提案者の能力中項目 :2 資格等小項目 :1 資格等 会社の保有資格以外にも主任技術者等の配置予定技術者の資格 ( 実績 ) を評価対象として評価することも評価の重要な点と考えます 大項目 :1 提案者の能力中項目 :3 プロジェクト全体計画小項目 :3 構築体制 において, 評価いたします 4 提案書の記載方法等 1 項番 :7 大項目 :1 提案者の能力中項目 :3 データセンター概要小項目 :1 データセンター概要 提案で利用するデータセンターの場所を 市町村名 のレベルでとありますが, 弊社 ASP サービスにおけるセキュリティポリシー上, 契約締結以前の状態で, 所在地に関する情報は秘匿事項に指定されており, 関西地区, 関東地区といったレベルまでの提供しかできませんがご容認頂けますかご検討お願い致します なお, 付帯情報として, 該当地点の地質, 標高, 浸水等の災害に対する危険情報, 交通の利便性等に関する情報等の提供は可能となっています なお, 契約締結後については詳細な位置の開示は可能となっています 次のとおり, 提案書記載内容欄に追記 追記前 場所 ( 市町村名のレベルでかまいません ) 追記後 場所 ( 市町村名のレベルでかまいません 提案者のセキュリティ上の理由により市町村名が記載できない場合は, 該当地点の地質 標高 浸水地域に該当するか否かの情報等により場所をご説明ください ) 5 提案書の記載方法等 2 項番 :17 大項目 :5 ハードウェア構成中項目 :1 ハードウェア構成小項目 :1 ハードウェア構成 提案システムのハードウェア構成 ( 案 ) については, 弊社 ASPサービスにおける次のとおり, 提案書記載内容欄 ( 文末 ) に追記セキィリティポリシー上, スペックやメーカ等の詳細は, 秘匿事項に指定されてお 追記内容 り, その内容を記述することが困難ですが, ご容認いただけますかご検討お願い提案者のセキュリティ上の理由により詳細な機器スペックが記載できないいたします 場合は, その旨を御記載の上, 機能別のサーバ構成, 外部ネットワーク / なお, ハードウェア構成, ネットワーク構成については, その配置, 機能別の DMZ/ 内部ネットワークの区別等, 概念図レベルの記載で可とします サーバ構成,Internal DMZエリアの区分等の概念図レベルまでの提示は可能です 当 GIS の調達範囲 (2) 当調達に含めないもの 当調達にふくまれないものとして 1~4 の項目が記載されていますが, 本業務内で 1~4 を実施できる提案にはその他評価で加点評価をしてほしい 特に,4 電子データ ( 地図データ ) の更新は重要と考えます 仕様書 更新頻度 において, 航空写真以外の背景図は少なくとも年 1 回は最新の情報を反映することを要求しています 仕様書に記載している以上の提案がある場合は, 提案書の記載方法 ( 案 ) 大項目 :10 その他中項目 :1 追加提案小項目 :1 追加提案 において評価いたします 1/8

2 当 GIS の構築スケジュール 関連箇所 当 GIS と連携する庁内他 GIS もこの時期に改修終了予定 意見 連携要件で考慮した提案が必要と考えられる為, 具体的にはどのような GIS を指しているのか提示して頂けないでしょうか 具体的なシステム名は明示できませんが, 次のとおり, 仕様書を改訂します 改訂前 ( 当 GIS と連携する庁内他 GIS もこの時期に改修終了予定 ) 改訂後 (1.2(4) に記したとおり庁内共用型に求める機能の一部又は全部について既存の庁内他 GIS にその役割を担わせる場合, 当 GIS と連携するその庁内他 GIS もこの時期に改修終了予定 ) サービス提供方式 要求機能の本文には, システムのサービス提供方式として ASP(SaaS) 方式 によることと指定されておりますが,GIS ソフトウェア ( 本案件で構築されるシステム ) そのものは神戸市様の資産としてご購入いただき,GIS ソフトウェアをデータセンターに預ける仕組み ( ホスティングサービス ) で提案したいと思いますが問題はありますでしょうか? 仕様書記載のとおり, 神戸市として資産を持たない ASP(SaaS) 方式 とします 仕様書の変更はいたしません Dos 攻撃対策 本項目は市民公開機能部分だけでなく, 庁内共用機能についても要求されるでしょうか 当社では, 庁内共用機能を配置するネットワーク区画はインターネットとは切り分かれたセキュアな環境での構築を予定するため, 庁内共用機能に対する Dos 攻撃を想定していません そのため, 本要件は市民公開機能のみ, あるいはインターネットデータセンターに配置する場合のみに限定した記載に修正頂きたく考えます 当仕様は, 庁内共用機能についても要求いたします 庁内共用機能を配置するネットワーク区画をインターネットとは切り分かれたセキュアな環境で構築するなど, 庁内共用機能に対する Dos 攻撃を想定する必要がない場合は, その旨を提案書, 機能実現証明書に御記載ください 10 応札者の事務所から30 分以内に駆けつけ可能な場所にデータセンターが存在当要求仕様では, サーバー機器のハードリセットなどの対応を想定していしていること とありますが, 弊社 ASPサービスでは, データセンターに対して機ます 器設置の契約以外に, 機器の保守管理についても委託契約を行っているため, 仕様書 3. 非機能要件 3.10 その他項番 : 再委託 に基づ緊急時の機器の動作監視や再起動, ネットワークからの分離等, 急を要するようき, 再委託先として提示された事業者のデータセンター 事務所は, 本提案な対応が可能となっています データセンターに対して再委託申請を行う前提とにおける 応札者の事務所 とみなします して, データセンターを応札者の事務所の一部として扱うことの可否についてご指示をお願いいたします 11 応急復旧対応は, 当社内保守環境よりデータセンタに接続して対応することが上と同じ 可能なため30 分以内に対応開始できます また, データセンタには当社契約の ( 当社契約の担当者 とは再委託先であると解釈しました ) 担当者が常駐しており, 現地対応が必要な簡易な作業も30 分以内に開始可能です ただし, 当社で予定するデータセンタ自体は, 当社事業所から公共交通機関を利用して約 180 分圏内のため, 本要件を事業所社員が現地作業開始までの時間とする場合には,30 分ではなく180 分に修正頂きたく考えます 応急復旧を30 分以内に着手するという意図でしたら, そのような記載に修正願います 2/8

3 12 関連箇所 当サーバ等に障害が発生した場合,8:00~23:00 の時間帯は少なくとも 30 分以内に対応開始できること ( 応札者の事務所等から 30 分以内に駆けつけ可能な場所にデータセンターが存在していること ) 意見 30 分以内の場所に事務所があることを仕様上の必須条件として特定しなくても良いのではないか 実際には, リモート操作若しくは常駐しているデータセンターの保守要員で即対応着手可能な状態で, 確実に 30 分以内に対応開始であれば良いのではないでしょうか ( 同様の条件での複数自治体での契約実績あり ) 当要求仕様では, サーバー機器のハードリセットなどの対応を想定しています 仕様書 3. 非機能要件 3.10 その他項番 : 再委託 に基づき, 再委託先として提示された事業者のデータセンター 事務所は, 本提案における 応札者の事務所 とみなします ( 常駐しているデータセンターの保守要員 とは再委託先であると解釈しました ) 当サーバ等に障害が発生した場合,8:00~23:00の時間帯は少なくとも30 市民サービスとして, 平日 休日を問わず8:00~23:00のサービス時間帯を分以内に対応開始できること とありますが, 地域の中小企業ではこの対応時間想定しています 仕様変更はいたしません を9:00~18:00に設定頂かないと厳しい場面があります 勿論,18 時以降や早朝も, 最大限対応できるように,2 名以上のSEの携帯番号へ直接連絡頂ける準備はしておきます 仕様内の文章に関しては時間帯の縮小が出来ないかご検討をお願いいたします 14 当サーバ等に障害が発生した場合 とありますが, 通信事業者の回線の故障も含まれるのでしょうか 回線の故障の場合は, その通信事業者の体制等も考慮する必要があるかと思いますので, 等 を省かれるか, 通信事業者の回線故障を除く 等, 明記された方がよいかと思います 要求仕様は, 対応完了までの時間ではなく対応着手までの時間を 30 分以内とすること, 及び当市への現地状況の報告を求めているものです 通信事業者の回線の故障の事実が分かった時を対応開始とみなすものと解釈してください 仕様変更はいたしません 職員端末の識別 操作者個人も ID とパスワード等により特定できるものとする とありますが ID, パスワードの管理に関する項目が必須項目になっていないように見受けられます システム内で保持する情報を組み合わせることで, 個人を特定できる情報を持つ必要があるのでしょうか それとも外部サーバと連携して初めて個人情報となり得る情報のみを保持する形に限定すべきでしょうか つまりシステム内で操作者情報を全て保持すべきか, 外部サーバの参照による比較で済むのかについて明記をお願い致します ( 例,ID とシステム固有のパスワードのみ保持している場合は,ID と個人情報 ( 個人名, その他 ) を結びつける外部システムを介さない限り個人を特定できません ) ID と個人情報 ( 個人名, その他 ) の管理は当市でも行います 提案システムでは ID ごとの権限管理, 操作ログ取得等の管理を行うものと理解してください また次のとおり, 仕様書を改訂します 改訂前 操作者個人も ID とパスワード等により ( 略 ) 改訂後 操作者も ID とパスワード等により ( 略 ) 操作ログの保管 当社システムでは, ユーザ ID( 操作者 ) に対する操作ログを記録 保存することは可能ですが, このログには, 機器の端末情報を特定する記録が困難なため, 本要件を修正頂きたく考えます 次のとおり, 仕様書を改訂します 改訂前 システム管理担当が操作する職員端末, 保守端末については操作者を特定できるようにする 改訂後 システム管理担当が操作した記録については,ID 等により操作者を特定できるようにする 3/8

4 サービス提供時間帯 通信事業者の回線メンテナンス工事は含まれるのでしょうか 通信事業者のメン仕様書 サービス提供時間帯の要求機能に次のとおり追記テナンス工事については, 通信事業者の工事に依存となりますので, 通信事業 追記 者の回線メンテナンスは除く 等, 明記された方がよいかと思います ただし, 通信事業者の回線メンテナンス工事など提案者自身の範疇外についてはユーザ ( 市民 職員 ) に事前告知する場合は上記の例外とする なお, 他者のメンテナンス工事などについてもサービス提供停止時間が最短となるよう努めること サービス提供時間帯変更 通信事業者の回線メンテナンス工事は含まれるのでしょうか 通信事業者のメンテナンス工事については, 通信事業者の工事に依存となりますので, 通信事業者の回線メンテナンスは除く 等, 明記された方がよいかと思います 一般閲覧用端末 OS:Windows7 とありますが Windows7 は 32bit 環境でしょうか, それとも 64bit 環境でしょうか どちらの bit 数かによってシステムの必要メモリが変わりますので情報の追記をお願いいたします 一般閲覧用端末については,WindowsVista 以降の OS についてサポートを必須とします Windows7 も 32bit,64bit 双方への対応を必須とします 仕様の変更はいたしません 一般閲覧用端末 関連箇所 ブラウザ :Internet Explorer 7 以降 の他,( 以下は必須でなく加点要素 )Mozilla Firefox,Safari,Google Chrome,Opera 等の主要なウェブブラウザなお,Internet Explorer 8 以降の旧ハ ーシ ョン互換機能使用による動作は対応しているとは認めない 意見 本稼働開始自体も 2 年近く先であり, 原則論として開始前に一般利用者のブラウザの普及率やシェア ( 例えば 40% 以上等 ) を確認した上で, 両者で協議して決める方法を取った方がアクセシビリティ上良いのではないか 一般閲覧用端末については, メーカーサポートのある OS を基準と考えており,H までは WindowsVista 及び InternetExplorer 7 の対応を必須としています 仕様の変更はいたしません 一般閲覧用端末 スマートフォン OS:Android,iOS とありますが対応するもっとも古いバージョンについての明記がありません 例えば Android2.3 では javascript でのマルチタッチに対応しておらず ios5 では html でのファイルアップロードに対応出来ていないという最新版との違いがあり, 全要件を全バージョンについて満たすというのはかなり厳しいかと考えます 是非もっとも古い対応バージョンについての明記をお願いいたします 最新版への対応は必須としますが, それ以外の古いバージョンへの対応については, 対応可能なものを提案書に御記載ください 提案書の記載方法 ( 案 ) 大項目 :8 システムの操作性中項目 :1 スマートフォン対応等小項目 :1 スマートフォン対応等 において評価いたします 想定同時アクセス数と処理速度 同時アクセス数 (1) 要求機能として, 同時アクセス数が 300 台 と指定されておりますが, 実際には同時アクセス数 100 台 程度が妥当ではないでしょうか? 要求機能本文の中には セッション維持中の端末 と書かれておりますが, 弊社といたしましては 同時に地図移動など の操作を 300 人 ( 台 ) の方が行われると想定しており, その際, パフォーマンスを確保するためにハイスペックのハードウェア仕様が必要となり, 神戸市様がご提示される予算に入らない可能性があります 可能であれば, 同時アクセス数を 100 台 としていただきたく存じます 次のとおり, 仕様書を改訂します 改訂前 300 台 改訂後 100 台 なお,100 台以上の提案が可能な事業者は, 仕様書 で加点いたします 4/8

5 想定同時アクセス数と処理速度 閲覧性能 関連箇所 例えば当市ハザードマップにおいては, 背景図の他に, 土砂災害警戒区背景図と選択レイヤーの合計が5 面以内の想定で, 要求ボタン押下から背景域 ( 急傾斜地 ) 河川浸水が想定される区域 津波警戒地域 など約 20レ図 レイヤーの表示の開始まで概ね5 秒以内, 描画完了まで10 秒以内とする ( 責イヤが存在しています 任分界点である当市庁内ネットワークとの境界で測定又は推定できること ) これらの情報より,3-3.3 閲覧性能に要求仕様として記載している 性能測 意見 定方法 手法 性能を担保する措置など を提案書に具体的に御記載くださ市として性能についての目標値があり, 性能測定する為には5 面以内と想定さい れるレイヤーががどういったものを想定されているか具体的な例示をお願いでき提案書の記載方法 ( 案 ) 大項目:7 SLAの内容中項目 :1 SLAの内容ないでしょうか 小項目 :1 SLAの内容 において評価いたします 想定同時アクセス数と処理速度 遅延表示 データインポート等のあらかじめ時間がかかる機能については, 進捗状況を表示を実装していますが, 突発的な負荷が発生する場合には, サーバ負荷だけでなく, ネットワークトラフィック等による原因の可能性もあり, すべてのケースに対して表示ができるわけではありません システム利用者が システム停止 なのか 遅延 なのか, 又は ネットワーク障害等 なのか判断できることが望ましいと考えています 実施内容については, 提案書の記載方法 ( 案 ) 大項目 :6 ソフトウェア構成中項目 :1 ソフトウェア構成小項目 :9 遅延表示 において評価いたします 庁内他 GIS からのインポート 庁内他 GIS から主題図のデータをインポートできる とありますが, 貴市のデータ整備状況を勘案すると, ほとんどのデータが平面直角座標系第 Ⅴ 系で作成されているものと推察されるため, それらのデータを事前に変換無く取り込むという認識で宜しいかご教示ください なお, システム内での座標系の管理は, システム内任意の座標系, 投影法の採用が可能か, 貴市より規定されたものを採用するか, ご指示いただけるようお願いします 今回, 提案のシステムにおいて内部での座標系は任意のものを採用して構わないものとします 庁内他 GIS において使用している座標系は平面直角座標系第 Ⅴ 系に限定するものではありませんので, データをインポートする際に指定された座標系のデータを, 必要に応じ変換し取込む仕様としてください 庁内他 GIS からのインポート 関連箇所 インポートする規模は構築時は新規で 1,000 レイヤー以内, 運用時は置換え ( 色, 透過度等は既存と同じ ) で毎月 200 レイヤー以内とする 意見 ここでいうレイヤーは最小単位, 最下層のレイヤー数という解釈で良いのでしょうか 例えば当市ハザードマップにおいては, 背景図の他に, 土砂災害警戒区域 ( 急傾斜地 ) 河川浸水が想定される区域 津波警戒地域 など約 20 レイヤが存在しています ここでは 土砂災害警戒区域 ( 急傾斜地 ) が 1 つのレイヤに相当するものとご理解ください WMS プロトコル対応 現在の利活用の状況を詳しくお聞きすることは可能でしょうか? データ連携の 1 つの手段として捉え代替案を提示することは問題ないでしょうか? 刻々と変化する降雨情報の受信, 災害時の当市の対応状況などの配信を想定しています 代替案をご提示いただいても構いませんが,WMS プロトコル実装以上に市民 ( データを欲する事業者を含む ) 当市職員に負荷がかからない形での代替案提示をお願いします WMS プロトコル対応 意見 WMS プロトコル対応について市民公開型 GIS の WMS 対応ですが, 要求される座標系は緯度経度に対応する形で良いのでしょうか ご意見のとおり 5/8

6 他システムからのリンク 庁内共用機能は, 当社では.netFramework のアプリケーションの導入を想定しているため,URL 等が存在しません そのため, 本要件は市民公開機能部分に対する要件として明記頂きたく考えます 要求仕様における庁内共用機能において, ブラウザによる主題図の閲覧, 簡単な編集を否定するものではありません 仕様の変更はいたしません 保守 システム導入後のシステム技術支援 ( コンサルティング ) も利用促進には重要な当市職員への庁内利用促進など仕様書に記載している以上の提案がある項目と考えれます この点を仕様書等に明記されたほうが良いと考えます ここ場合は, 提案書の記載方法 ( 案 ) 大項目:10 その他中項目 :1 追加提でいう技術支援は 年 回庁内利用促進協議会 (WG 等 ) を開催 支援する, 年案小項目 :1 追加提案 において評価いたします 回庁内地理空間情報の新たな利活用の検討を行う 等のサポートを想定しています 保守 セキュリティ対策 緊急時の場合は, 貴市の適用可否の判断によらず, 速やかに自主的に設定を行います 実施結果については, 報告を行います 当 GIS の稼働に支障がある場合 ( パッチをすぐに適用できない場合 ) に限っては, 対応結果を協議によって決定します そのため, 本要件の記載方法 ( 貴市に報告のうえで対策をとる という順序 ) を修正頂きたく考えます 緊急時においても速やかに当市に報告, 当市による適用判断の上で対策を実施するようにしてください なお, 当市への報告方法, 時間帯等については契約締結時に別途協議するものとします 仕様の変更はいたしません その他 再委託 システム運用を再委託する場合など, 提案時にその旨を記載すること とありま次のとおり, 要求機能欄に追記すが, 再委託先の会社名を記載すると, その関係から応札者の社名が推察され 追記前 る可能性があり, 公平性に欠く可能性が出てきます 提案時においては, 再委託提案時にその旨を記載すること なお, 再々委託は認めない の可否についてのみ記載することとし, 再委託先の具体的な社名等について 追記後 は, 受託契約後に提示する措置をとることの可否についてご指示をお願いいた提案時にその旨を記載すること ( 再委託先事業者名は提案書に記載せします ず, 別紙提示とすること ) なお, 再々委託は認めない 関連箇所 トップページ等を別に作成しても, しなくても構いません 公開レベル 意見 画面というのは各 GIS 利用時の利用画面のことでトップページ等を別に作成するという意味ではないと解釈して良いのでしょうか 市民へのオープンデータ提供機能 RDF 形式 要求機能として, 提供可能なデータの一覧をRDF 形式でWeb 上で提供するものと当市では今後,RDF 形式によるデータ提供が普及していくものと考えてお記載されておりますが,RDF 形式はまだそれほど世の中に普及しておらず, 可能ります であれば仕様から外していただきたく存じます 仕様の変更はいたしません 6/8

7 4.5 庁内共用機能 分析機能 カーネル密度推定は, 個別 GIS 等の専門性の高い分野での利用が多いと考え, 統合型製品での利用を想定していません そのため, 本要件を仕様書より除外頂きたく考えます カーネル密度推定, 任意地点間のルート検索, ルート断面など当仕様においては希望項目であり必須項目ではありません 実現可能な機能については, 仕様書記載のとおり 庁内共用画面 で総合的に評価いたします 仕様の変更はいたしません 庁内共用機能 統計データ表示 要求機能の本文に記載のある カルトグラム による表示機能は, 余り利用用途がないものと推察いたしますが, どのような局面で利用されるのでしょうか? 本表示機能は複雑な開発が伴う機能となり, それほど利用シーンが明確でないのであれば仕様から外していただきたく存じます カルトグラムなど当仕様においては希望項目であり必須項目ではありません 実現可能な機能については, 仕様書記載のとおり 庁内共用画面 で総合的に評価いたします 仕様の変更はいたしません 庁内共用機能 統計データ表示 カルトグラムは, 個別 GIS 等の専門性の高い分野での利用が多いと考え, 統合型製品での利用を想定していません そのため, 本要件を仕様書より除外頂きたく考えます 庁内共用機能 URL 庁内共用機能は, 当社では.netFramework のアプリケーションの導入を想定しているため,URL が表示されません そのため, 本要件は市民公開機能部分に対する要件として明記頂きたく考えます 要求仕様における庁内共用機能において, ブラウザによる主題図の閲覧, 簡単な編集を否定するものではありません 仕様の変更はいたしません 背景図 縮尺 背景図に使う地図は調達事業者が確保すること とありますが, ランニングコスト要求仕様は仕様書にあるとおり 2 千 5 百分の1の背景図では, 幅概ね4m が今回の範囲で運用できない様な住宅地図やネット配信されているような地図, 以上の道路が判別でき, 全家屋形状が表示され利用者が使いやすい注記また, 地理院様の無償の地図まで, 様々にございます システム構築の提案の表現であること 特に公共施設, 商業ビル, 店舗, 集合住宅名所が十分に中で, 地図のランニングコストの問題もありますが, 神戸市様の許容範囲の地図確認できること とします でなかった場合の問題が選択に不安を感じております できれば推奨される地なお, 上記を満たすか否かは, 提案書の記載方法 ( 案 ) 大項目:6 ソフト図を御示し頂けないでしょうか ウェア構成中項目 :1 ソフトウェア構成小項目 :4 背景に使う地図 において判断いたします 背景図 航空写真 貴市資産税課様が3 年毎に撮影している成果を搭載することを考えています ( 庁航空写真は当仕様においては希望項目であり必須項目ではありません 内資産の有効活用のため ) なお, 搭載にあたっては, 情報化推進部様より資産仕様の変更はいたしません 税課様の使用許可をとって頂くことを想定しています 7/8

8 背景図 航空写真 航空写真を事業者が調達し, システムの背景図として利用できることが指定されておりますが, 航空写真ではなく衛星画像ではいけないでしょうか? また, 神戸市様が保有される航空写真 ( 課税調査等で定期的に撮影されているものと推察 ) を背景図として利用する提案はできないでしょうか? 航空写真は当仕様においては希望項目であり必須項目ではありません 仕様の変更はいたしません 背景図 更新頻度 本システム掲載データ以外にも新たな地図情報の掲載や他システムとのデータ連携が考えられますが, これらのデータ掲載の対応や地図データの更新等も本業務 ( 平成 26~32 年度 ) の範囲内に含まれるのか明確に記載願います 仕様書 3.5-1,3.5-5,4.7-9,4.8-8 に記載のとおり, 他システムとの連携や地図データの更新が必要です 当市としては, 職員が操作しやすい端末とした上で, 定例的なデータ更新作業等の職員による作業も削減できればよいと考えています これらについては, 提案書の記載方法 ( 案 ) 大項目 :1 提案者の能力中項目 :3 プロジェクト全体計画小項目 :4 保守 運用の体制 及び 大項目 :8 システムの操作性中項目 :2 職員端末小項目 :1 職員端末 において判断いたします 主題図 規模 システム上に初期搭載される地図データを 2,400 レイヤーと定められておりますが, この初期データのセットアップ作業は業者 ( 弊社 ) 側での作業として見込んだ方がよろしいでしょうか? 弊社の提案では, 神戸市の職員様が自らデータをセットアップできる仕組みを提案するつもりでおります これらについては, 提案書の記載方法 ( 案 ) 大項目 :1 提案者の能力中項目 :3 プロジェクト全体計画小項目 :3 構築体制 及び 大項目 :8 システムの操作性中項目 :2 職員端末小項目 :1 職員端末 において判断いたします 主題図 関連箇所 例えば当市ハザードマップにおいては, 背景図の他に, 土砂災害警戒区当初は2,400レイヤー ( 以下省略 ) 域 ( 急傾斜地 ) 河川浸水が想定される区域 津波警戒地域 など約 20レ 意見 イヤが存在しています ここでいう2,400レイヤーは最小単位, 最下層のレイヤー数という解釈で良いのでここでは 土砂災害警戒区域 ( 急傾斜地 ) が1つのレイヤに相当するものとしょうか ご理解ください 主題図 統計データ表示 統計データのエクセル表を入力する 機能を実装するとありますが, こちらは管理機能として対応するという意味でしょうか? また, 保守作業による対応は不可でしょうか? 一般職員による操作になります 主題図 更新頻度 関連箇所 主題図は月 1 回 200 レイヤーまでの更新を想定する 意見 主題図の月 1 回の更新は職員側で更新が可能な機能を用意した場合でも, 事業者側で月 1 回更新作業が必要ということになるのでしょうか 仕様書 3.5-1,3.5-5,4.7-9,4.8-8 に記載のとおり, 他システムとの連携や地図データの更新が必要です 当市としては, 職員が操作しやすい端末とした上で, 定例的なデータ更新作業等の職員による作業も削減できればよいと考えています これらについては, 提案書の記載方法 ( 案 ) 大項目 :1 提案者の能力中項目 :3 プロジェクト全体計画小項目 :4 保守 運用の体制 及び 大項目 :8 システムの操作性中項目 :2 職員端末小項目 :1 職員端末 において判断いたします 8/8