使用多个摄像头的单个多车辆停车位的控制使用的制作方法与工艺

本发明涉及使用摄像头来识别车辆并且跟踪和控制车辆使用停车位。

背景技术：
各种市政和私人停车场经营者具有广泛的传统停车管理系统，用于管理对车辆的目标位置(例如，用于轮式机动车辆的停车位)的使用，并且获得该使用的收益。通常将这种传统系统升级为完全自动化需要大量返工和费用，从而造成了大量前期资本投资，使得很多停车场经营者无法进行这种升级。需要一种完全自动化和自主停车管理系统，该系统容易与现有停车支付系统整合，包括已经安装并且操作一段时间的系统。这样做，为停车设施操作员开启了先前未开发的新收入机会和效率。

技术实现要素：
在一个实施例中，提供一种跟踪使用至少一个目标位置的方法，所述方法包括：接收由多个摄像头捕捉的多个车辆图像，其中，每个车辆图像包括第一车辆的图像，多个摄像头包括第一识别摄像头，多个摄像头包括目标摄像头，车辆图像包括由第一识别摄像头捕捉的一个或多个第一识别图像，由目标摄像头捕捉的多个目标图像包括在第一时间捕捉的第一目标图像、在第一时间之后在第二时间捕捉的第二目标图像以及在第二时间之后在第三时间捕捉的第三目标图像；根据第一识别图像，确定第一车辆的第一唯一标识符；根据第一识别图像，确定第一车辆的多个第一特征；根据一个或多个目标图像，确定车辆的多个第二特征；确定多个第二特征与多个第一特征对应；根据确定多个第二特征与多个第一特征对应，确定在多个目标图像内包括第一车辆的图像；根据第一目标图像和第二目标图像，确定第一车辆停在第一目标位置；根据第三目标 图像，确定第一车辆离开了第一目标位置；指示第一车辆在第一时间开始使用第一目标位置；以及指示第一车辆在第三时间完成使用第一目标位置，其中，其中，接收、确定以及指示前述步骤由一个或多个计算机执行，所述计算机共同被编程为执行前述步骤。一种非瞬时计算机可读介质，其包括指令，在执行时，所述指令使得一个或多个计算机执行：接收由多个摄像头捕捉的多个车辆图像，其中，每个车辆图像包括第一车辆的图像，多个摄像头包括第一识别摄像头，多个摄像头包括目标摄像头，车辆图像包括由第一识别摄像头捕捉的一个或多个第一识别图像，由目标摄像头捕捉的多个目标图像包括在第一时间捕捉的第一目标图像、在第一时间之后在第二时间捕捉的第二目标图像以及在第二时间之后在第三时间捕捉的第三目标图像；根据第一识别图像，确定第一车辆的第一唯一标识符；根据第一识别图像，确定第一车辆的多个第一特征；根据一个或多个目标图像，确定车辆的多个第二特征；确定多个第二特征与多个第一特征对应；根据确定多个第二特征与多个第一特征对应，确定在多个目标图像内包括第一车辆的图像；根据第一目标图像和第二目标图像，确定第一车辆停在第一目标位置；根据第三目标图像，确定第一车辆离开了第一目标位置；指示第一车辆在第一时间开始使用第一目标位置；以及指示第一车辆在第三时间完成使用第一目标位置。由所公开的主题获得的各种优点包括但是不限于：(1)为违规停车传票提供不干涉的自我执行；(2)为违规停车传票提供不干涉的自我执行，其与现有“原地”停车支付基础设施整合；(3)与依赖于识别仅仅一个或非常少的车辆的近距离传感器的技术相比，使用更小数量的传感器以及相关联的安装成本的降低，该因素对在大型露天区域(例如，停车场)内停车位的管理很重要；(4)利用商用现货(COTS)技术以及设备成本的相关联的降低，用于车辆检测和停车执行；(5)基于软件的车辆检测技术的改进可以在整个系统中快速地更新，尤其在远离摄像头执行图像处理的实施例中，并且在整个停车管理系统中实现车辆检测的改进，而无需硬件变化；(6)在系统范围的系统行为或者与停车位 的更窄定义的子集相关的方面快速地进行变化的能力。附图说明图1示出了根据所公开的主题的总体系统100的一个实例；图2A和2B示出了由识别摄像头捕捉的图像的实例；图3A和3B示出了由目标摄像头捕捉的图像的实例；图4示出了由具有重叠的视场的摄像头捕捉的图像可以用于识别车辆、跟踪车辆到目标位置的运动以及识别车辆使用目标位置的方式；图5为示出了计算机系统500的方框图，在该系统上可以实现本发明的方面；图6A和6B示出了用于规定摄像头的视场的特征的图形用户界面(GUI)的方面，图6A示出了显示第一摄像头的图像的一部分GUI，图6B示出了显示第二摄像头的图像的一部分GUI。具体实施方式图1示出了根据所公开的主题的总体系统100的一个实例。网络110提供在图1中显示的部件之间的数据通信服务。具有多个网络技术，包括但不限于以太网、802.11无线以及蜂窝数据网络技术，本领域的技术人员可以可靠地并且可预测地整合这些技术，用于在所显示的部件之间交换数据。在一个实施例中，可以使用单独的网络。例如，摄像头120和125以及服务器140可以通过第一网络通信，而其他部件通过公共网络通信。通过使用单独的第一网络，本领域的技术人员可以实现可靠性和安全性的预期目标。识别摄像头120示出了包含在系统100内的多个这种摄像头中的一个。为了方便讨论，在图1中仅仅显示了单个识别摄像头120。识别摄像头120定位成可以捕捉车辆标识符的图像，例如但不限于汽车牌照或附着于车辆的标签，该标签以例如但不限于QR代码或条形码的形式提供车辆标识符。由识别摄像头120捕捉的图像(例如，图像121)与由一个或多个目标摄像头125捕捉的 图像相结合使用，以便识别单独的车辆(例如，车辆130)并且记录其对各种目标位置的使用。用于轮式机动车辆的目标位置的实例包括被指定为适合停车的区域(虽然可能受到各种限制)以及被指定为不适合停车的区域。，适合停车的区域为例如但不限于停车位，不适合停车的区域为例如但不限于汽车站、防火线、消防栓周围区域、人行道、在十字路口的X英尺内的区域、车道、安全岛、分离带、自行车道、人行横道。。例如，服务器系统140可以被配置为确定车辆停在汽车站的时间，并且基于该确定来请求或者采取行动，例如，请求拖曳车辆或者通过邮件发出传票。在一个实施例中，可以识别其他违规停车，例如，车辆未适当地停在指定的停车位内、停放位与路边相距1英尺以上、左轮朝着路边停放(朝着错误的方向停放)、倒进车位、以及丢弃车辆(连续X天以上留在特定的位置)。在一个实施例中，识别摄像头还可以包括移动或手持式摄像头，包括(例如)包含在智能电话内的摄像头。目标摄像头125示出了包含在系统100内的多个这种摄像头中的一个。为了方便讨论，在图1中仅仅显示了单个目标摄像头125。目标摄像头125定位成可以捕捉一个或多个目标位置的图像，例如但不限于汽车停车位。通常，目标摄像头125安装在某个高度，例如但不限于安装在灯杆或电话线杆上，或者安装在建筑物的外墙或顶部上。通过将目标摄像头125安装在某个高度，由目标摄像头125捕捉的图像(例如，图像126)的视场可以包括并且因此用于监控多个目标位置。在一个实施例中，目标摄像头还可以包括移动或手持式摄像头，包括(例如)包含在智能电话内的摄像头。在一个实施例中，目标摄像头可以包含在停车计时表主体内。在一个实施例中，目标摄像头可以由空间卫星成像摄像头提供，将会消除在整个城市安装目标摄像头的需要。在实施例中，目标摄像头可以包含在飞行器内，例如但不限于软式飞艇或其他飞艇或者无人机，并且可以在更长的飞行时间自主操作。虽然识别摄像头120和目标摄像头125可以被配置为均通过各自的通信链路127和128与网络110直接通信。在另一实施例中，识别摄像头120可以被配置为与目标摄像头125直接通信并且通过目标摄像头转发数据，以便识别摄 像头120不被配置为通过通信链路127与网络110直接通信，而是通过通信链路129与目标摄像头125通信，并且目标摄像头125通过通信链路128与网络110通信，以便目标摄像头125用于将数据转发给识别摄像头120并且转发来自识别摄像头的数据。通信链路129可以是无线网络链路。虽然图1示出了在这两个摄像头120和125之间具有通信链路129的一个实例，但是可以扩展为通过多个摄像头转发数据，将数据发送给特定的摄像头或者从特定的摄像头发送数据。此外，可以在多个摄像头之中建立无线网状网络，在摄像头间提供容错的以及自我配置的无线通信介质。通过使用无线通信代替硬接线链路，可以减少总体上在系统内的硬接线的通信链路的数量以及与安装和维修这种硬接线链路相关联的费用和劳动。而且，这可以作为使用，例如，蜂窝数据通信来将数据传送给网络110的替代方案，这是因为蜂窝数据通信的成本通常明显大于通过硬接线链路。然而，不需要无线通信，并且部分或全部摄像头可以通过硬接线链路通信。服务器系统140包括一个或多个计算机系统，其提供中央数据存储、数据检索以及处理服务。包含在服务器系统140内的计算机系统通常均包括随机存取存储器142和处理器143。服务器系统140包括数据库141，其用于记录信息，例如，车辆使用目标位置(例如，停车位)、车辆账户信息、通过识别摄像头图像获得的车辆的识别、通过目标摄像头图像获得的车辆的观察、目标预留信息、计费信息、以及支付信息。例如，可以使用软件程序(例如，MySQL、Oracle或DBASE)实现数据库141。数据库141可以包括通过多个计算机系统执行的多个数据库实例。在一个实施例中，服务器系统140被配置为从由识别摄像头(例如，识别摄像头120)和目标摄像头(例如，目标摄像头125)中捕捉的图像中执行车辆和车辆身份识别。进一步地，服务器140被配置为根据所识别的信息进行决策，例如，确定目标位置的使用，以及何时在目标位置的使用违反目标位置的使用限制。图像处理和决策集中于服务器系统140中的这个实施例利用了摩尔(Moore)定律和尼尔森(Nielsen)定律，在摩尔定律中，在微处理器内的晶 体管的数量以及数据处理能力的相应量每18个月翻倍，Nielsen定律假设带宽速度每年增长50％。通过这种集中方法，可以实现显著的效益。不仅可以通过越来越便宜和快速的CPU功率，快速放大服务器应用程序的智能/特征丰富性，而且新特征和应用程序还可以快速地进入现场“瘦客户端”装置。通常通过在整个系统中使用COTS(商用现货)元件，减少制造成本。此外，高度网络化系统将非常适合利用通过网络获得的技术服务的更新。最后，随着微处理器和带宽成本继续降低，可以通过越来越小的成本，实现尺寸或容量的扩大。在另一个实施例中，一些功能可以分布到该系统的其他组成部分中。例如，识别摄像头120可以被配置为在捕捉的图像中识别车辆识别信息，例如，车牌号。在该实施例中，在识别摄像头120与服务器系统140之间的数据通信量以及服务器系统140必须执行的处理量可以大幅减少，代价是识别摄像头120需要为更复杂的装置，该装置能够执行图像处理功能，这些功能能够(例如)在识别图像内的车辆、识别图像内的车辆识别信息和/或从图像中提取车辆识别信息。通过另一个实例，识别摄像头和目标摄像头可以编程为确定车辆图像的特征，下面结合图4详细说明，而非使用服务器系统140进行这种确定。总体上在整个系统中分布功能的方式会取决于提供分布功能的预期成本(例如，为识别和/或目标摄像头提供必要的处理硬件和编程)、这些成本与将由摄像头捕捉的图像传送给中央位置用于处理的预期成本权衡。正好在本领域技术人员的惯常做法是，将编程功能从一个计算机系统移动到另一个计算机系统，以容纳通信瓶颈，例如，从服务器系统140移动到识别摄像头120，并且确保提供充足的处理资源，用于各种计算机系统执行这些功能。移动装置150包括可编程计算机、识别摄像头以及无线数据通信能力，用于与服务器系统140通信。在一个实例中，如果确定车辆130正在使用目标位置，但是未确定车辆130的唯一标识，那么移动装置150可以被发送至目标位置以及捕捉车辆130的图像151，从该图像中，可以获得车辆130的唯一标识。除了捕获车牌照的图像以外，与识别摄像头120所进行的那样，移动装置150还可以被配置为捕捉车辆VIN标识符标签，这可以有助于没有车牌照的车辆。 由于穿过了识别摄像头120的视场，所以这帮助克服偶然情况，例如，由另一个车辆阻塞车辆130，其中，识别摄像头120不能捕捉对唯一识别车辆130有效的图像。多个移动装置可以包含在系统内，以便更好地确保在由服务器系统140管理的所有目标位置上即时捕捉图像。在一个实施例中，移动装置150还可以被配置为提供对停止执行有用的特征。例如，移动装置150可以被配置为给由服务器系统140识别的违规停车打印出纸件传票。现场支付系统160是多个装置中的一个，该装置通常位于一个或多个目标位置附近，为终端用户提供直接物理接口，以提交支付使用目标位置的付款或协议。支付系统160的实例包括但不限于专用于单独的目标位置的停车计时表、与几个街道停车位相关联的支付站、以及用于位于停车场或停车库内的目标位置的支付站。在一个实施例中，现场支付系统160可以包括为一个或多个目标位置捕捉图像的目标摄像头。终端用户系统170是可编程计算机系统，通过该系统，终端用户(例如，车辆130的驾驶员)可以与服务器系统140交互。这些系统的实例包括但不限于具有网页浏览器应用的台式计算机系统、具有网页浏览器应用或专用停车应用的智能电话、以及包含在车辆130内的车载式系统。终端用户系统170可以用于(例如)创建终端用户账户，用于与服务器系统140反复交互、预留使用目标位置、请求识别可用目标位置以及提交使用目标位置的支付信息。在一个实施例中，终端用户系统170可以被配置为从服务器系统140请求和获取描述给定区域内可用目标位置的信息。在一个实例中，终端用户系统170可以进一步被配置为获取和/或请求可接受的目标位置的特定标准，例如，在停车库或者非街道上停车(例如，停车场)内的目标位置。除了位置信息以外，终端用户系统170还可以获得其他信息，例如但不限于给定的目标位置的使用价格。终端用户系统170可以进一步被配置为请求和获取当前可用的目标位置和/或在未来特定时间点或范围可用的目标位置的信息。终端用户系统可以进一步被配置为将图形用户界面提供给终端用户，图形用户界面显示从服务器系统140获得的一个或多个可用目标位置的具体位置(例如，在地图上)。在一个实 施例中，在停车设施(例如，停车库或停车场)处有多个目标位置可用，终端用户系统170可以被配置为广泛地表示在停车设施处的目标位置的可用性(可能表示可用目标位置的数量)，而非单独地识别每个目标位置。终端用户系统170可以被配置为从终端用户中接收所选目标位置的指示。终端用户系统170可以进一步被配置为提供至所选目标位置的指引(例如，导航)。终端用户系统170可以进一步被配置为指令服务器系统140预留可用目标位置。人工审查系统180是编程的计算机系统，通过该系统，人工操作员181为服务器系统140提供帮助，用于识别车辆，例如，车辆130。例如，服务器系统140可以确定在从由识别摄像头120捕捉的图像(例如，图像121)中执行车辆130的唯一标识符的基于自动化机器的确定时发生错误。响应于这个错误，服务器系统140可以请求人工操作员181帮助确定车辆130的唯一标识符，例如，车牌号。人工审查系统180提供用户界面，通过该界面，人工操作员181可以审查图像121，并且可能审查由识别摄像头120或其他摄像头捕捉的其他图像。例如，人工操作员181可以手动回放录像片段以及向前定格，以便手动确定车牌号和州/省份信息。通过这个界面，人工操作员181可以提供车辆130的识别或者表示人工操作员181不能确定车辆130的识别，这将使得移动装置150被分派给目标位置，以便进行车辆130的准确识别。根据由服务器系统140处理的信息量，可以有多个人工审查系统180供服务器系统140使用。此外，人工操作员181可以是现场操作团队的成员，下面更详细地讨论。在一个实施例中，一个或多个识别和目标摄像头通过比从摄像头中传送给服务器系统140的图像更高的帧速率和/分辨率捕捉图像。虽然由这种摄像头捕捉的所有图像数据并非都传送给服务器系统140，为了保留可能昂贵的网络通信带宽(例如，蜂窝数据网络)以及服务器系统410处有限的可用图像处理资源，这种摄像头可以缓存有限数量的其捕捉的完整图像数据，例如，缓存在环形缓冲器内。此外，这种摄像头被配置为针对这种额外图像数据的请求作出响应，例如，包括可用于牌照识别的更高分辨率图像的部分。通过这种机制，服务器系统140可以自动确定额外图像可用于识别和跟踪车辆，或者人工审查系 统180可以请求各种图像，以便解决服务器系统140产生的错误。停车操作系统190是编程的计算机系统，通过该系统，停车设施经营者可以与服务器系统140交互并且控制服务器系统140。预期服务器系统140在大部分时间自主操作，停车场经营者需要很少的输入。然而，偶尔有停车设施经营者积极参与其操作的实例。例如，停车操作系统190可以提供现场指示来指示有多少个目标位置以及哪个目标位置正在使用的和/或可用。作为另一个实例，停车操作系统190可以对车辆违反使用限制的目标位置提供现场指示，使得停车设施经营者在其认为必要时对这种违反采取行动。图2A示出了由识别摄像头120捕捉的图像121的实例，其中，识别摄像头120被定位在可以有效地捕捉经过该识别摄像头120的车辆的识别信息的位置。在实施例中，识别摄像头120使包含识别信息(例如，车牌信息)的图像的视频流入服务器系统140中。由于典型的路灯具有大约18英尺的高度，所以为识别摄像头提供极好的安装位置，获得远离树木和其他障碍物(包括靠近行驶的车辆)的清晰视线。而且，由于已经为路灯提供了电源，所以可以将识别摄像头安装为从路灯中获取电力。此外，由于大部分城市条例要求在街道的每个地点上的每个街区具有至少一个路灯，所以路灯安装的识别摄像头可以给横穿街道的任何车辆提供充足的覆盖范围。由识别摄像头120捕捉的识别图像用于两个主要目的：(1)获得车辆的唯一识别，例如，通过从安装在车辆的前面或后面的车牌照中读取标识符；以及(2)确定车辆的各种特征，以便可以确定另一个摄像头获得的车辆的图像对应于所识别的车辆，下面将结合图4进行讨论。在图2A中显示的实例识别图像中，车辆的视图及其牌照可由服务器系统140进行处理。多个识别图像可用于确定车辆特征，例如，行驶速度和方向。在车牌照读取器领域中，在本领域中已知各种技术，用于可靠地捕捉图像，有效地用于在各种照明和车辆情况下可靠地读取车辆标识符。在美国专利No.7,016,518中，描述了一个非限制性实例，其全文并入本文中，以作参考。在实施例中，由于在晚上缺乏自然照明，使用目标位置的限制仅仅在白天有效的问 题可以避免。在实施例中，识别摄像头120可以执行用于获得车辆标识符的机器视觉技术。在这种实施例中，识别摄像头120发送给服务器系统140的数据量可以大幅减少，这是因为可以发送车辆标识符来代替识别图像。然而，一个或多个识别图像依然可以被发送给服务器系统140，用于由服务器系统140存储和/或确定车辆特征(虽然在实施例中，这还可以由识别摄像头120完成)。在一个实施例中，服务器系统140可以认识到该系统仅仅能够获得一部分车辆标识符，也许是因为某些特定的条件，例如，车辆或紧随其后的车辆的角度。在这种情况下，服务器系统可以进一步依赖于由第二识别摄像头捕捉的第二识别图像，来获得标识符的剩余部分。图2B示出了由识别摄像头120捕捉的图像121的实例，其中，识别摄像头120所在的位置使其可以有效地捕捉通过沿着识别摄像头120的视图轴延伸的道路进入和离开城市交叉口的车辆的识别信息。在这个识别图像中，三辆车辆的视图有效地由服务器系统140处理，从而可以从单个图像中获取全部三辆车辆的唯一标识符。在实施例中，识别摄像头120可以具有摇摄、倾斜和/或变焦功能，这可以使得服务器系统140能够获得车辆的更详细的视图，或者使得停车设施经营者通过停车操作系统190上的用户界面能够监视可由识别摄像头120看到的特定兴趣区域。在这种实施例中，服务器系统140可以被配置为在改变识别摄像头120的视场时，进行坐标变换以便精确地确定车辆特征。在一个实施例中，当车辆在识别摄像头120的视场中出现时，服务器系统140执行6项任务中的一个或多个。在第一任务中，服务器系统140根据由识别摄像头120捕捉的一个或多个图像，检测一个或多个车辆的存在。在一实施例中，服务器系统140可以被配置为根据车辆与背景之间的色差以及确定潜在车辆的整体形状的尺寸大于为任何适用的缩放水平调整的特定最小车辆尺寸，检测车辆的存在。具体而言，这种算法可以将图像中的所有像素的颜色进行相互比较。像素分成行和列(例如，绝对位置21、34可以表示位于行21和列34 上的像素)。由于图像可能包括其他非车辆物体，例如但不限于消防栓、行人、汽车、草地、或道路标记/油漆，所以该算法可以被配置为检测具有相似颜色的像素组(可以在系统配置内规定被视为相似的颜色的范围，例如，相似的颜色可以最大具有2个阴影差异，参照由比色图表表示的阴影)。然后，在数学上计算这些像素的位置，以确定是否形成比最小车辆尺寸更大的形状(例如，相对尺寸10x30可以表示10行乘以30列的形状测量)。由于视角的原因，在由识别摄像头120捕捉的图像中出现的车辆在形状上常常似乎是平行四边形，而非矩形。因此，进行确定时可以考虑这个因素。由于(例如)太阳反射、挡风玻璃区域或行李架，可以进行进一步的改善，以调整所检测的形状中的“孔”或缺点。例如，算法可以规定相距彼此高达某个距离(或像素)的特定最小尺寸的多个形状，其可以对应于车辆的部分，例如，通常具有相同的颜色的引擎盖、车顶以及行李箱。一旦检测到了车辆，就在与识别摄像头120对应的数据库141部分中记录条目，随同包括(例如)日期、时间、车辆颜色、车辆尺寸、像素位置以及缩放水平的信息。这个信息可以与该车辆的其他检测相结合使用，以识别车辆。或者，这种信息可以暂时记录在易失性存储器(例如，RAM)内。在第二任务中，服务器系统140在由识别摄像头120捕捉的图像中检测车辆上的车牌照和/或额外识别(例如但不限于贴花)。一旦检测到了车牌照和/或额外识别，就在与识别摄像头120对应的数据库141部分中记录条目，随同包括(例如)日期、时间、车牌照#、州/省、贴花细节(例如，类型、标识符和有效期)、像素位置以及缩放水平的信息。这个信息可以与车辆的其他检测相结合使用，以在其他图像(例如，由目标摄像头捕捉的图像)中识别车辆。在第三任务中，服务器系统140根据由识别摄像头120捕捉的多个图像来识别相对静止的车辆移动的车辆。在第四任务中，服务器系统140根据由识别摄像头120捕捉的多个图像来识别相对静止的车牌照和/或额外识别移动的车牌照和/或额外识别。在实例中，服务器系统140可以被配置为：(1)根据从当前图像中(例如，通过OCR)获 得的车牌照和/或额外识别信息，在先前的图像中找出相应的匹配(例如，通过审查存储在数据库141或存储器中的数据)；(2)一旦找到这种匹配，比较当前图像与先前图像之间的像素的位置，考虑缩放水平的任何变化。根据这种处理，可以检测一个或多个以下场景。(A)如果像素的位置未改变或者在预定的阈值之下还未改变，那么所有车牌照和/或额外识别被视为依然静止。在这种场景下，为车辆在数据库141或存储器内的现有条目进行日期和时间的简单更新。(B)如果与一个或多个车牌照和/或额外识别相关联的像素在新的位置，那么确定该一个或多个车牌照和/或额外识别已移动。服务器系统140可以计算这些车辆的行驶速度和方向并且以这种信息以及更新的位置来更新数据库141或存储器。(C)如果一个或多个车牌照和/或额外识别从当前图像中消失，那么服务器系统140可以被配置为删除该车辆在数据库141或存储器中记录的数据。(D)如果一个或多个车牌照和/或额外识别刚刚在当前图像中出现，那么可以在数据库141或存储器中记录与新车牌照和/或额外识别相关联的数据。在实施例中，服务器系统140可以确定一个新车辆与最近被确定消失的车辆对应，可以将车辆的视图视为被暂时遮住。(E)如果所有车牌照和/或额外识别都从当前图像中消失，那么删除来自前述间隔的数据库141或存储器中与车牌照和/或额外识别相关的数据。然而，可以保留一些数据，以便执行进入或来自识别摄像头的车辆跟踪，如上所述。在第五任务中，服务器系统140将识别的车牌照和/或额外识别与在第一任务中检测的车辆配对。例如，服务器系统140可以被配置为将车牌照和/或额外识别(例如，绝对像素位置、行驶方向和速度)的属性与为可能的车辆确定的这种属性进行比对，并且尝试使每个车牌照和/或额外识别与车辆配对。在第一到第五任务中，服务器系统140可以应用机器视觉技术，以识别在车辆上的额外识别，用于确认特定的车辆有资格停在特定的停车位内，或者车牌照登记目前有效。这种其他类型的唯一识别包括但不限于：残疾人停车贴花或反射镜悬挂物、居民专用停车贴花、以及通常依附于车牌照的注册贴花。在第一到第五任务中，可以在任何车牌照图像上执行OCR(光学字符识 别)，以便获得字母数字车牌照号以及发行州/省。要注意的是，观察的车牌照可以是前或后车牌照(通常，提供通过这两种方式指向街道来回移动的识别摄像头)。所获得的车牌照信息用于获得唯一车辆标识符，用于在数据库141中记录关于车辆的信息。在某些配置中，第一任务可以在识别摄像头上本地执行，其中，车牌照号和州/省数据通过简明的数据格式传输给服务器系统140。在识别摄像头120与服务器系统140之间的底层通信网络未提供充足的带宽(例如，1Mb/秒可以视为流图像的最小阈值)或者视为太昂贵(例如，大于$10/MB)时尤其如此。多个车辆可以同时存在于识别图像121内。在一实施例中，服务器系统140可以在任何给定的时间同时从单个识别摄像头中跟踪高达10组车牌号信息。在第六任务中，车辆在穿过识别摄像头120的视场时被“跟踪”。在由识别摄像头120捕捉的图像与相邻的目标摄像头125之间具有重叠，以便车辆在这两个摄像头的视场内，以15MPH(大约44英尺)的速度持续最少2秒钟。通常，确定相邻或附近的摄像头位置确保发生这种重叠。由于这两个摄像头具有独特地不同的视角，从这两个摄像头中获得任何给定车辆的重叠图像，被视为车辆的准确识别(通过从识别图像121中获得的车牌号)以及车辆占据(如果车辆停车)的精确目标位置。在一个实施例中，初步运动检测可以用于减少捕捉和/或分析的识别图像的数量，这是因为在大量时间内没有任何车辆穿过识别摄像头120的视场。OCR速率在评估识别性能时仅仅是有用测量中的一种。例如，虽然令人印象深刻的是，在所记录/捕捉的100车牌照之中，服务器系统140仅仅没有OCR其中1个车牌照(换言之，不能产生字母-数字车牌号)，但是如果这种配置(包括服务器系统编程、识别摄像头定位以及识别摄像头图像质量)没有捕捉/登记100个其他车牌(换言之，服务器系统140不这样识别额外的车牌图像)，那么总体效能仅仅是49.5％。而且，车牌识别系统通常调谐成从特定的州/省中读取车牌照以及从多个周围的州/省中读取车牌照。各种州/省的车牌照具有不同的颜色和字母和背景对比。在一个实施例中，捕捉率至少是95％，并且OCR精度 至少是95％，产生至少90.25％的最小总体效能。图3A示出了由目标摄像头125捕捉的图像126的实例，其中，目标摄像头125位于建筑物的外墙或顶部上，向下观察城市街道的一部分，由此在图像126中看到车辆的顶视图。与在图3A中显示的图像126对应的视场相关联，9个合适的目标位置310a到310i(例如，停车位，按照使用小时收费)被指定给服务器系统140。在这些之中，除目标位置310d外全部由车辆310a到310i使用。同样被指定给服务器系统140的还有不合适的目标位置340(例如，商业入口)。如果车辆通过保持静止一段时间被确定使用了目标位置340，那么车辆被视为违规，使得服务器系统140主动采取行动，例如但不限于收取违规罚款或者警告停车设施操作员该违规。在一些实施例中，车辆在任何未被识别为目标位置的区域内保持静止均会被视为违规。在图像126中还可以看到车辆330，位于车辆在图像中从左到右行驶的行车道中。单独来看，单个图像未表示车辆330是移动还是静止。例如，在前一个图像中，车辆330可能使用目标位置310d，并且这个图像可以使服务器系统140确定车辆330刚刚使用完目标位置310d。由目标摄像头125捕捉的目标图像用于两个主要目的：(1)识别车辆使用或不使用目标位置的时间；以及(2)确定车辆的各种特征，通过确定从由相邻摄像头捕捉的图像中确定的特征是否彼此对应，以便在车辆在摄像头之间横穿时，可以跟踪车辆，如下面结合图4所述。图3B示出了由目标摄像头125捕捉的图像126的实例，其中，目标摄像头125定位成在图像126中看到车辆的侧视图。目标摄像头125位于现场停车系统160内(例如，停车计时表)、或者位于与一个或多个兴趣目标位置相对的建筑物或结构上，可以获得这种视图。与对应于图3B中显示的图像126的视场相关联，4个合适的目标位置350a到350d(例如，停车位，按照使用小时收费)被指定给服务器系统140。在这些之中，除目标位置350c外全部似乎由车辆360a到360d使用。在另一个实例中，在图中未显示，目标摄像头125可以定位为使图像126提供一个或多个目标位置的立体图。虽然图3A和3B显示了目标位置的矩形区 域310和350的规格，但是可以使用其他形状，例如，多边形(在目标摄像头125定位成看到目标位置的立体图的情况下可用)。下面结合图6A和6B描述的GUI还可以被配置为提供用户界面部件，其可以用于通过在图像种子上的重叠规定目标位置在摄像头的视场内的位置和范围。此外，GUI可以提供用于为目标位置分配标识符的工具，并且可能提供关于目标位置的各种特征，例如但不限于是否是停车位、“非停车”位置以及对使用的基于时间和/或日期的限制。在一个实施例中，当车辆出现在目标摄像头125的视场内时，服务器系统140执行两项任务。对于第一任务，服务器系统140可以被配置为：(1)意识到在目标摄像头125的视场内存在的任何和所有车辆；(2)区分移动和静止车辆；(3)识别移动车辆在与目标位置对应的视场的区域内变为静止的时间；(4)识别每个静止车辆正在占据哪个/那些目标位置；(5)记录每个车辆占据其各自的目标位置的时间长度；(6)识别静止车辆腾出与目标位置对应的视场的区域的时间；(7)确定目标位置的使用与给目标位置建立的限制冲突的时间；(8)识别车辆错误地停车的街道或街区；(9)跟踪每个车辆错误地停车的时间量；(10)跟踪车辆停止非法停车的时间。用于轮式机动车辆的各种类型的目标位置(每个位置具有各自的限制)包括但不限于：非停车区域(任何时间、消防车道、消防栓)、在特定的时间和/或日期非停车(例如，在高峰时间或街道清扫期间)、非停车/停止/停顿、有限时间停车(例如，2个小时的时间限制)、限于车辆类别的停车(出租车招呼站、汽车站、装卸区/商用专用车辆)、允许停车(残疾人或居民专用停车)、上客和下客专用位置、以及街道交叉口(为了抵抗交通堵塞，“阻塞方框”行车违规，其中，在车辆行驶方向，在红灯期间，车辆保持在交叉口内)。服务器系统140可以被配置为检测其他违规停车，例如但不限于在交叉口的规定距离内停车、在自行车道或人行横道或其他步行区停车、不在单个目标位置的空间内停车、与路边相距超过规定的距离停车、在车道内或之前停车、使用安全岛或中央带停车、车辆朝着错误的方向停车、丢弃车辆(静止超过规定的天数)、大型车辆、错误的车辆类别(例如，在规定的天数内超过规定的小时数的野营车、拖车或船只)。目标位置还可以进行预留，其中， 终端用户预留专用目标位置规定的时间段。服务器系统140还可以被配置为检测双停放车辆，同时区分由驾驶条件造成在行车道中停止的车辆和错误地双停放车辆。服务器系统140还可以被配置为识别并且在某些情况下区分更小的轮式车辆，例如，摩托车、踏板车以及“智能汽车”。在第二任务中，车辆在穿过目标摄像头125的视场时被“跟踪”。在由目标摄像头125捕捉的图像与相邻识别或目标摄像头之间具有重叠，以便车辆在这两个摄像头的视场内，以15MPH(大约44英尺)的速度持续最少2秒。通常，确定相邻的摄像头位置确保发生这种重叠。由于这两个摄像头具有独特地不同的视角，从这两个摄像头中获得任何给定车辆的重叠图像，被视为车辆的准确识别(通过从识别图像121中获得的车牌号)以及车辆占据(如果车辆停车)的精确停车位。在一些配置中，目标摄像头可以定位成监视特定区域内的车辆移动，其中，该区域不包括用于服务器系统140的任何兴趣目标位置。这种区域可以放在(例如)两个各包含兴趣目标位置的区域之间。在这个实例中，由目标摄像头捕捉的图像可以与由这两个区域对应的摄像头捕捉的图像重叠，并且可以用于“切换”程序，如图4中所示，下面进行讨论。在实施例中，目标摄像头125可以具有摇摄、倾斜和/或变焦功能，这可以使得服务器系统140能够获得目标位置的更详细的视图，或者使得停车设施经营者通过停车操作系统190上的用户界面能够监视可由目标摄像头125看到的特定兴趣区域。在这种实施例中，服务器系统140可以被配置为在改变目标摄像头125的视场时，进行坐标变换以监视目标位置的使用并且精确地确定车辆特征。在实施例中，初步运动检测可以用于减少捕捉和/或分析的识别图像的数量，这是因为在大量时间内没有任何车辆穿过目标摄像头125的视场。在实施例中，如果需要，可以在由识别摄像头和目标摄像头捕捉的所有图像内包括精确的日期和时间戳，以方便之后的所存储图像的人工审查。在实施例中，在确定在合适的目标位置(不同于不合适的目标位置，例如， 非停车区域)内静止之后，给予车辆某个量的“宽限期”。在驾驶员离开车辆去支付停车时，即使确定车辆开始使用目标位置，而未进行支付，也需要某个宽限期，以延迟确定车辆违反付费使用要求，这是因为需要某个时间量来完成支付流程。图4示出了由具有重叠的视场的摄像头捕捉的图像可以用于识别车辆、跟踪车辆到目标位置的运动以及识别车辆使用目标位置的方式。图4不按规定比例显示；例如，覆重叠区域430a在标称上在垂直方向扩展44或更大英尺，但是显示为与车辆410具有大约相同的尺寸。首先，在时间t1，识别摄像头(未显示)捕捉覆盖在图4中显示的视场的识别图像420。在识别图像420内指定为410'的位置，包括车辆410。根据图像420a(并且可能是在时间t1之前，由识别摄像头捕捉的额外图像)，服务器系统140确定车辆410的唯一标识符。通过在车牌照的一个或多个检测的图像上执行OCR，以获得车牌号，从该车牌号中可以获得唯一标识符。服务器系统140根据该唯一标识符在数据库141内记录由识别摄像头在时间t1观察到车辆410。在一个替换的实施例中，服务器系统140改为在易失性存储器内保存由识别摄像头在时间t1观察到车辆410，并且在由服务器系统140通过从除了捕捉识别图像420的识别摄像头以外的识别摄像头中获得的识别图像识别车辆410之前，在确定车辆410使用了目标位置之后，在数据库141内记录上述保存的信息。在时间t2，识别摄像头在指定为410a的位置捕捉车辆410的另一个识别图像420a'。在大约时间t2，第一目标摄像头在重叠区域430a内(例如，在大约位置410a)捕捉车辆410的目标图像420b。在一些实施例中，识别摄像头和第一目标摄像头同步，以便在基本上相同的时间t2捕捉图像420a'和420b。重叠区域430a对应于与目标图像420b的视场重叠的识别图像420a'的视场。在图像420a'和420b中，当车辆410在重叠区域430a内时，捕捉车辆410的图像。根据由识别摄像头捕捉的一个或多个识别图像(例如，识别图像420a')，服务器系统140确定车辆410的多个特征Ca。如上所述，车辆410的并且记录在数据库141内的固定特征可以包含在Ca内。特征的实例包括但不限于：车 辆410的行驶速度、车辆410的行驶方向、在车辆图像内的车辆的位置(例如，包括车辆410行驶的行车道)、车辆410的颜色以及车辆410的尺寸或大小。一些特征可以视为车辆410的静态特征，不会随着时间改变(例如，车辆颜色或尺寸)。其他特征可以视为车辆410的动态特征，并且可以随着时间大幅改变(例如，车速或行车道)。在实施例中，静态特征可以作为车辆410的固定特征记录在数据库141，该固定特征与根据识别图像420a确定的唯一标识符相关。可以根据由终端用户提供的车辆信息(例如，牌子、型号、年份以及颜色)或者基于车辆410与服务器系统140之间的前次相遇期间捕捉的车辆图像，确定这些固定特征。通过确保从识别图像中确定的静态特征与固定特征对应，这些固定特征可以用于确定车辆410的唯一标识符。固定特征还可以包含在Ca或者确认车辆识别的其他多个特征内。根据目标图像420b以及或许其他由第一目标摄像头捕捉的目标图像，服务器系统140确定车辆410的多个特征Ca'。由于车辆410针对识别摄像头和第一目标摄像头的不同视角以及阻塞车辆等因素，Ca和Ca'可以由不同的但是通常重叠的几组车辆特征构成。例如，由于在时间t2，从第一目标摄像头的角度来看，车辆410被部分阻碍，使得可以为Ca而不能为Ca'确定车辆宽度。此外，图像的失真(在边界或者图像处通常更为显著)以及其他因素会导致某些车辆特征(例如，速度或尺寸)仅仅是近似值。可以执行特征(例如，尺寸、速度以及行驶方向)的标准化，以补偿摄像头定位和缩放水平。然后，通过比较包含在Ca和Ca'内的车辆特征的值，服务器系统140确定Ca'是否与Ca对应。由于由服务器系统140确定的车辆特征可以是车辆410的实际特征的近似值，所以在值之间的近似等值足以支持确定Ca'与Ca对应，其中，表明这种等值用于所有比较的特征。如果确定Ca'与Ca对应，那么服务器系统140在数据库141根据唯一标识符记录第一目标摄像头在时间t2观察到车辆410。在一个替换的实施例中，服务器系统140改为在易失性存储器内保存第一目标摄像头在时间t2观察到车辆410，并且在由服务器系统140通过从除了捕捉识别图像420的识别摄像头以外的识别摄像头获得的识别图像中识别车 辆410之前，在确定车辆410使用了目标位置之后，在数据库141内记录上述被保存的信息。这样避免了将不需要表明车辆410使用特定目标位置的车辆位置信息写入数据库141内。在时间t3，第一识别摄像头在指定为410b的位置捕捉车辆410的另一个识别图像420b'。在大约时间t3，第二目标摄像头在重叠区域430b内(例如，在大约位置410b)捕捉车辆410的目标图像420c。在一些实施例中，第一识别摄像头和第二目标摄像头同步，以便在基本相同的时间t3捕捉图像420b'和420c。重叠区域430b对应于与目标图像420c的视场重叠的目标图像420b'的视场。在图像420b'和420c中，当车辆410和440在重叠区域430b内时，捕捉车辆410和440的图像。根据由第一目标摄像头捕捉的一个或多个目标图像(例如，识别图像420b')，服务器系统140确定车辆410的多个特征Cb。如上所述，车辆410的并且记录在数据库141内的固定特征可以包含在Cb内。根据目标图像420c以及或许其他由第二目标摄像头捕捉的目标图像，服务器系统140确定车辆410的多个特征Cb'。此外，由于在目标图像420c内包括车辆440，所以为车辆440确定多个车辆特征Cx。由于车辆440在相反的方向行驶在不同的行车道中，使Cb'与Cx之间具有动态车辆特征上的差异。然后，服务器系统140确定Cx是否与Cb对应，这应该不会发生。然后，服务器系统140确定Cb'是否与Cb对应。如果Cb'确定与Cb对应，那么服务器系统140根据唯一标识符在数据库141内记录第二目标摄像头在时间t3观察到车辆410。在一个替换的实施例中，服务器系统140改为在易失性存储器内保存第二目标摄像头在时间t3观察到车辆410，并且在由服务器系统140通过从除了捕捉识别图像420的识别摄像头以外的识别摄像头获得的识别图像中识别车辆410之前，在确定车辆410使用了目标位置之后，在数据库141内记录上述保存的信息。在时间t4，第二目标摄像头在指定为410c的位置捕捉车辆410的另一个目标图像420c'。在大约时间t4，第三目标摄像头在重叠区域430c内(例如，在大约位置410c)捕捉车辆410的目标图像420d。在一些实施例中，第二目标摄 像头和第三目标摄像头同步，以便在基本相同的时间t4捕捉图像420c'和420d。重叠区域430c对应于与目标图像420d的视场重叠的目标图像420c'的视场对应。在图像420c'和420d中，当车辆410在重叠区域430c内时，捕捉车辆410的图像。根据由第二目标摄像头捕捉的一个或多个目标图像(例如，识别图像420c')，服务器系统140确定车辆410的多个特征Cc。如上所述，车辆410的并且记录在数据库141内的固定特征可以包含在Cc内。根据目标图像420d以及或许其他由第三目标摄像头捕捉的目标图像，服务器系统140确定车辆410的多个特征Cc'。然后，服务器系统140确定Cc'是否与Cc对应。如果Cc'确定与Cc对应，那么服务器系统140根据唯一标识符在数据库141内记录第三目标摄像头在时间t4观察到车辆410。在一个替换的实施例中，服务器系统140改为在易失性存储器内保存第三目标摄像头在时间t4观察到车辆410，并且在由服务器系统140通过从除了捕捉识别图像420的识别摄像头以外的识别摄像头获得的识别图像中识别车辆410之前，在确定车辆410使用了目标位置之后，在数据库141内记录上述保存的信息。在一个实施例中，第二识别摄像头可以负责捕捉图像420d，但是不能获得车辆410的车牌照的图像，在这种情况下，通过第二识别摄像头观察到的车辆的特征用于确认在区域410c周围的重叠区域430c内观察到的车辆是车辆410。这表明了，在车辆410驶离初始识别摄像头时，是目标摄像头还是识别摄像头用于跟踪车辆410并不重要。在用于这种跟踪时，这些摄像头可以被广泛地称为“跟踪摄像头”。在时间t5，第三目标摄像头在指定为410d的位置捕捉车辆410的另一个目标图像420d'。在大约时间t5，第四目标摄像头在重叠区域430d内(例如，在大约位置410d)捕捉车辆410的目标图像420e。在一些实施例中，第三目标摄像头和第四目标摄像头同步，以便在基本相同的时间t5捕捉图像420d'和420e。重叠区域430d对应于与目标图像420e的视场重叠的目标图像420d'的视场。在图像420d'和420e中，当车辆410在重叠区域430d内时，捕捉车辆410的图像。根据由第三目标摄像头捕捉的一个或多个目标图像(例如，识别图像 420d')，服务器系统140确定车辆410的多个特征Cd。如上所述，车辆410的并且记录在数据库141内的固定特征可以包含在Cd内。根据目标图像420e以及或许其他由第四目标摄像头捕捉的目标图像，服务器系统140确定车辆410的多个特征Cd'。然后，服务器系统140确定Cd'是否与Cd对应。如果Cd'确定与Cd对应，那么服务器系统140根据唯一标识符在数据库141内记录第四目标摄像头在时间t5观察到车辆410。在一个替换的实施例中，服务器系统140改为在易失性存储器内保存第四目标摄像头在时间t5观察到车辆410，并且在由服务器系统140通过从除了捕捉识别图像420的识别摄像头以外的识别摄像头获得的识别图像中识别车辆410之前，在确定车辆410使用了目标位置之后，在数据库141内记录上述保存的信息。与图4中显示的图像420e的视场相关联，4个合适的目标位置450a到450d(例如，停车位，按照使用小时收费)被指定给服务器系统140。在时间t6，在车辆410位于位置410e时，由第四目标摄像头捕捉目标图像420e'。根据目标图像420e'，服务器系统140确定车辆410在指定给目标位置450b的矩形区域内。在时间t7，目标图像420e”由第四目标摄像头捕捉，车辆410依然在位置410e。根据目标图像420e"，服务器系统140再次确定车辆410在指定给目标位置450b的矩形区域内，因此，确定车辆410在时间t6开始使用目标位置450b，并且在数据库141内记录这个信息。在时间t8，在车辆410离开了目标位置450b时，由第四目标摄像头捕捉目标图像420e”'。根据目标图像420e”'，服务器系统140确定车辆410不再位于指定给目标位置450b的矩形区域内，因此，确定车辆410在时间t8完成使用目标位置450b。根据关于适用于从时间段t6到t8使用目标位置450b的限制的信息，例如，目标位置450b的使用小时收费，服务器系统140可以开始行动，例如，针对目标位置450b的使用向终端用户账户开具账单，或者例如，针对目标位置450b的不当使用征收罚款。服务器系统140还被配置为正确地识别使用了目标位置的车辆，其中，服务器系统140首先确定车辆使用了目标位置，之后，能够通过识别摄像头捕捉车辆识别。可能会发生这种情况，例如，在车辆穿过识别摄像头时，车辆的视 图被遮挡，或者服务器系统140的重新启动导致未进行先前的车辆的识别。作为一个实例，如果在时间t0，在时间t1之前，第四目标摄像头欲首先确定车辆440使用目标位置450c，但没有车辆440的识别，那么将为车辆440分配临时唯一标识符，并且在数据库141中记录与临时标识符相关的条目。在车辆440使用目标位置450c时以及在其穿过重叠区域430d、430c、430b以及430a时，确定车辆440的车辆特征组，并且通过与上面描述的方式几乎相同的方式执行这些特征组的对应，以确定和记录与临时标识符相关联的车辆440依然被观察。在位于重叠区域430a内时，一旦被第一识别摄像头观察到，服务器系统140能够确定车辆440的正确唯一标识符。此时，先前根据临时标识符记录在数据库141内的记录可以被修改或再次保存为根据车辆440的正确唯一标识符的记录，目标位置450c的使用与该标识符适当地相关联。用于在时间t0之后获得车辆440的识别的一种替换机制为分派移动装置150，以在车辆440使用目标位置450c时捕捉车辆440的一个或多个识别图像。移动装置150的分派可以指定为具有更高的优先级，此时车辆440对目标位置450c的使用被确定为与目标位置450c的使用相关联的限制冲突。服务器系统140从识别和目标摄像头中接收图像，并且插入停放车辆的身份。然后，服务器系统140可以通过API(应用程序界面)从第三方停车支付系统中检索停车支付信息(例如但不限于支付过的停车的持续时间和到期时间)。如果车辆停放状态确定为未付费或到期，那么服务器系统140通过API将这个信息传输给第三方停车支付系统。然后，在处理违规停放(例如但不限于邮寄违规停车罚单、在车辆上安装车轮固定夹，或者在反复或者严重违规停车时拖车)时，运行第三方支付系统的停放设施操作员可以遵循其标准操作程序(SOP)。服务器系统140的车辆检测可以被配置为执行几个功能：(1)检测视频帧内车辆的存在和位置；(2)区分移动和静止车辆；(3)识别特定的被检测车辆是否正占据目标位置(例如，停车位或非停车区域)；(4)确定车辆开始占据或腾出目标位置的时间；(5)在车辆从一个跟踪摄像头的视场行驶到另一个跟踪 摄像头的视场时，跟踪车辆，并且如果在这个跟踪中确定发生了错误，那么引发异常。在实施例中，服务器系统140还可以被配置为识别特定的车辆是否显示了合适的指示符，用于进入或使用目标位置。这种指示符的实例包括但不限于残疾人停放悬挂物或贴花、或表示授权使用“居民专用”停放位置的停放悬挂物或贴花。摄像头可以变焦，以更明确地捕捉这种指示符的图像。在实施例中，车辆标识符(例如，车牌照)可以用于确定适当进入或使用目标位置，并且排除单独指示符的需要。在一个实施例中，服务器系统140可以编程为使用线程来执行识别和目标摄像头的任务。例如，“视频_接收器(video_receiver)”线程可以处理从标识符或目标摄像头中接收视频和/或图像流，并且保存原始视频和/或图像信息。每个视频和/或图像流或多个视频和/或图像流可以具有一个线程。这个线程的可配置的选项可以包括(1)保存到文件中，(2)保存到存储器中，(3)保存到存储器和文件中，(4)视频数据的保留时间(例如，4个小时)。另一个实例是以下线程：用于检测车辆颜色、形状、位置、车道位置、行驶速度/方向、车辆位置是否在切换区域(以及哪个区域)内、摄像头识别、以及在数据库141内保存这种信息。这个线程会检查多个视频帧，来确定更新的位置和车辆的行驶速度/方向并且在数据库141内保存这种信息。每个视频和/或图像流或多个视频和/或图像流可以具有一个线程。另一个实例是确认通过由附近摄像头检测的切换区域离开的特定车辆的线程。这可以，例如，根据被检测车辆所在的切换区域和/或被检测车辆的行驶方向，通过审查特定摄像头的数据库141来实现。每个视频和/或图像流或多个视频和/或图像流可以具有一个线程。另一个实例是以下线程：确定车辆是否通过在目标位置保持静止来占据该目标位置以及车辆开始占据或腾出目标位置的时间。每个视频和/或图像流或多个视频和/或图像流可以具有一个线程。在本领域中已知多种机器视觉技术，其可用于检测视频帧内车辆的存在。例如，具有各种已知的边缘检测算法，其可以用于检测车辆的存在。作为一个实例，算法可以根据车辆与背景之间的色差检测车辆的存在以及总体形状的尺 寸是否大于在考虑到在视野内的缩放水平和/或位置时预期的最小车辆尺寸。例如，该算法使在视频流快照内的像素的颜色彼此相比较。由于图像可能包括各种非车辆物体，例如，消防栓、行人、草地、道路标记以及油漆，所以该算法可以检测具有相似颜色(颜色变化具有可配置的范围被视为匹配)的像素组。在总体形状内的像素的数量和位置用于确定形状是否大于最小车辆尺寸。该算法可以进一步调整形状中的“孔”或缺点，这些例如由于镜面反射或高光产生。此外，该算法可以确定各自的最小尺寸的多个形状是否在彼此的某个距离内。这些形状可以与(例如)通常具有相同的颜色的车辆的引擎盖、车顶以及行李箱部分对应。在车辆与背景之间的颜色对比或差异不足时发生边界条件，此时，检测失败。例如，黑色车辆对黑色沥青。可以引入摄像头硬件和/或算法的进一步改进，以解决这个边界条件。例如，可以使用执行可见光和热成像的摄像头，该摄像头获得开始占据目标位置的车辆的热标签。在这个实例中，即使车辆和背景是黑色，发动机舱也具有与其周围不同的热剖面。进一步的成本效益分析确定从这组方法中获得的利益是否适合增量成本，并且考虑由热成像工艺造成的任何边界条件可以充分地解决(例如，通过由摄像头捕捉的可见光)。虽然从单个图像中可以识别车辆的存在和多个特征，但是需要多个图像，用来确定(例如)车辆是静止的还是移动的。在一个实例中，服务器系统140可以被配置为：(1)根据在当前图像中确定的车辆的颜色和尺寸，在先前的图像中找出相应的匹配(例如，通过审查保存在数据库141或存储器内的数据)；以及(2)一旦找到这种匹配，比较当前图像与先前图像之间的像素的位置，考虑缩放水平的任何变化。根据这种处理，可以检测一个或多个以下场景。(A)如果像素的位置未改变或者在预定的阈值之下还未改变，那么所有车辆被视为依然静止。在这种场景下，为车辆在数据库141或存储器内的现有条目进行日期和时间的简单更新。(B)如果与一个或多个车辆相关联的像素在新的位置，那么确定一个或多个车辆已移动。服务器系统140可以计算这些车辆的行驶速度和方向并且以这种信息以及更新的位置来更新数据库141或存储器。(C)如 果一个或多个车辆从当前图像中消失，那么服务器系统140可以被配置为删除该车辆在数据库141或存储器中记录的数据。(D)如果一个或多个车辆刚刚在当前图像中出现，那么可以在数据库141或存储器中记录与新车辆相关联的数据。在实施例中，服务器系统140可以确定一个新车辆与最近被确定消失的车辆对应，可以将车辆的视图视为被暂时遮住。(E)如果所有车辆都从当前图像中消失，那么删除前述间隔的数据库141或存储器中与该些车辆相关的数据。然而，可以保留一些数据，以便执行进入或来自识别摄像头的车辆跟踪，如上所述。在一个实例中，用于识别哪些车辆占据目标区域的算法与基本车辆检测算法相似。一旦完成车辆检测，服务器系统140就评估与车辆对应的像素位置是否占据任何预先映射的视觉区域。重叠的程度可以配置。在一个实施例中，可以应用垂直偏移，以补偿车辆高度和补偿在目标摄像头与车辆之间的视野障碍，例如，停放的车辆。例如，这种障碍可以在密集的停车场中频繁地发生。而且，服务器系统140确定车辆是否保持静止至少某个时间量。一旦确定车辆在目标位置内逗留至少某个时间量，就在数据库141内、优选地在非易失性存储器内记录车辆的识别信息、目标位置以及车辆开始使用目标位置的时间和日期。在实施例中，服务器系统140可以被配置为检测车辆占据多个目标位置的时间，例如，占据两个停车位。这可以造成(例如)发放一个或多个违规停车传票或更多的使用费用。服务器系统140还可以确定车辆腾出目标位置的时间，并在数据库141内记录相应信息。而且，服务器系统140可以被配置为确定车辆很快会超过或者已超过目标位置的使用时间，这在以下情形下会发生：具有两个小时的最大停放时长的停车位、在道路清扫的规定时间之后不可供车辆使用的目标位置，或者给车辆提供的资金的耗尽。在一个实施例中，服务器系统140可以被配置为识别一个或多个多车辆目标位置，这些位置一次可以供不止一个车辆使用。例如，服务器系统140可以被配置为支持跟踪车辆的“长街区”停放，其中，沿着城市街区的路边的长度，提供(例如)由单个空间付费、凭票泊车或牌照付费单元控制的停车区域，但 是停车区域不分成标记的停车位；相反，车辆可以沿着路边利用任何可用空间(不包括某些“非停车”区域，例如但不限于装卸区和车道)。在另一个实例中，服务器系统140可以被配置为跟踪使用停车场，而非(例如)由单个凭票泊车单元控制的在其内的多个单独标记的空间。虽然服务器系统140可以不被配置为逐个空间地跟踪使用多车辆目标位置，但是服务器系统140可以确定并记录车辆在多车辆目标位置中的位置，用于随着时间跟踪车辆的使用并且用于停车执法活动，例如，将传票贴到超过了其允许使用的多车辆目标位置的车辆中。在实施例中，服务器系统140可以被配置为确定车辆使用多车辆目标位置的长度，这是因为可以征收更大的停车费用和/或罚单，用于使用可以由不止一个车辆占据的空间。使用在本申请中描述的服务器系统140的一个益处在于，常规的控制的停车场可能依赖于单个进出点，用于控制使用停车位，然而，使用摄像头来跟踪，允许停车场具有多个入口和出口，并且具有更“开放的”设计，这是因为车辆不需要由围栏的壁来限制。在一个实施例中，多个不连续的目标位置或多车辆目标位置可以聚合到单个多车辆目标位置内。这可以包括两个构成的目标位置由不同的目标摄像头覆盖。例如，在多车辆目标位置由各种“非停车”目标位置沿着城市街区的长度分解的情况下，这可以有用。在一个实施例中，可以具有限制的目标位置(例如，覆盖多车辆目标位置的“非停车”)，以便“开拓”多车辆位置的限制区域。例如，在上面讨论的“长街区”场景中，可以沿着城市街区的整个长度，限定单个多车辆目标位置，“非停车”目标位置沿着城市街区覆盖各种部分，例如但不限于沿着街区的长度的装卸区和车道。尽管车辆也在更大的多车辆目标位置内，被服务器系统140检测为使用其中一个“非停车”目标位置的车辆被服务器系统140确定为违规停车。在一个实施例中，可以提供基于计算机的配置实用程序。例如，移动装置150或人工审查系统180可以配置有配置实用程序，允许现场或远程配置。例如，移动装置150可以由进行摄像头安装的人使用，以便提供关于用于车辆识 别、跟踪和/或检测的摄像头配置的效能的反馈。可替代地或额外地，在人工审查系统180的使用期间识别的配置缺点，可以通过人工审查系统180进行某些系统或摄像头配置改变。在实施例中，可以通过网页浏览器提供用户界面。配置实用程序可以提供一个或多个特征，例如但不限于：提供图形用户界面(GUI)，为给定的摄像头进行车辆检测的校准；提供GUI，用于确保连续的摄像头对准；提供GUI，用于规定最小车辆尺寸，这可以根据像素并且为缩放水平调整；提供GUI，用于识别与另一个摄像头的视场重叠的摄像头的视场的一部分；提供GUI，用于使摄像头对准和/或规定摄像头定向和/或对准；提供GUI，用于预先映射目标位置；限定被视为违规停车的情况，这种情况可以特别用于给定的区域或位置；配置各种违规停车的结果，例如，在屏幕上简单地显示违规的信息，可以获得登记持有人信息以用于签发传票或账单，或者可以打印警告并且将警告放在车上；配置使用期限，在使用期限之后，在通过邮件或其他方式签发违规停车传票之前，必须向国有机动车机构作出车辆持有人注册信息的新请求；提供GUI，用于审查和修改其他系统配置参数。为了为给定摄像头进行车辆检测的校准，GUI显示了两个图像种子，并且允许管理员在每个图像种子上叠加规则。如果有的话，可以显示缩放水平，作为GUI的一部分，这可以是修改缩放水平的控制。这两个图像种子源自具有重叠的视场的给定摄像头和另一个摄像头(这种摄像头通常彼此相邻)。优选地，为了进行校准，这两个摄像头的图像的捕捉同步，以便同时捕捉图像，允许在每个视频种子中审查车辆的位置，例如，在穿过这两个摄像头的视场的重叠区域时。配置实用程序还可以通过GUI提供时间图像控制功能，例如，暂停、播放、回放、快进、定格前进、定格倒退以及转到帧功能。为了进行校准，配置实用程序可以用于在一个或这两个图像种子(这可能包括(例如)由操作配置实用程序的技术人员使用的车辆)内找出已知牌子和 型号的一个或多个车辆，并在GUI内放置一个或多个标尺，以便参考正被测量的车辆的长度、宽度和/或高度的已知值，表示车辆的正确长度、宽度和/或高度。在实施例中，由GUI提供的标尺功能被配置为补偿非线性，该非线性是由例如由摄像头(例如，根据摄像头型号，这可以具有已知的特征)引入的视觉失真或者所捕捉的图像的立体图等因素造成。例如，表示距离单元的标尺标记可以在图像的右侧上更密切地隔开，其中，与在图像的左边捕捉的车辆相比，在该区域内捕捉的车辆离摄像头更远。配置实用程序可以被配置为允许通过识别在图像内的标记并且规定位置和/或距离(相对于其他标记和/或摄像头)，来为给定摄像头现场校准这种非线性。这种标记可以由技术人员暂时放置或者在某些情况下永久地放置以用于随后的重新校准。而且，配置实用程序可以用于规定两个图像种子中行驶方向之间的关系，以及识别与这两个图像种子中共同的点对应的像素或图像位置。在实施例中，可以规定在每个图像种子中的行驶车道/路径的位置和行驶方向，并且这些位置和行驶方向在这两个图像种子之间相关联(例如，允许稍后确定车辆在相同的行驶车道/路径内从一个摄像头的视场进入另一个摄像头的视场的时间)。可以通过GUI进行这些特征的详述，例如，通过允许在图像种子上覆盖指示车道/路径界限的线路或其他指示符。图6A和6B示出了一个实例GUI的方面。图6A示出了一部分GUI，其中，显示了来自第一摄像头的图像600a。图6B示出了一部分GUI，其中，显示了来自第二摄像头的图像600b。图像600a和600b的视场重叠，重叠的区域包括区域640a和640b。在图像600a和600b内还捕捉了两个行驶车道/路径，在图6A中标记为车道/路径611a和612a，并且在图6B中标记为车道/路径611b和612b。在图6A和6B中显示的这个特定的实例中，交通在车道/路径611a和611b中在相同的方向(通常与角度θ对应)进行，而在相似的实例中，交通可能在车道/路径611a和611b中在相反的方向进行。在图像600a和600b内还捕捉了三个车辆的图像，分别标记为A、B以及C。在图6A中，使用虚线车道/路径边界指示符621a、622a以及623a规定车道/路径边界，这些可以通过使用GUI来增加、放置、移动、标记以及识别。在图6A 中，使用GUI规定两个行驶车道/路径：在车道/路径边界指示符621a和623a之间的车道/路径611a，以及在车道/路径边界指示符622a和623a之间的车道/路径612a。在图6A中显示的特定的实例中，交通在车道/路径611a和612a中在相同的方向θ继续，并且车道/路径边界指示符621a和622a是第一类型(由相似的虚线表示)，并且车道/路径边界指示符623a是第二类型，其表示将在车道/路径边界指示符621a和622a之间的单向车流的区域分成两个车道/路径611a和612a。配置实用程序可以被配置为给给定的车道自动提供或建议标识符，用于交叉引用(例如)其他摄像头识别的车道，例如，在图6B中显示的车道/路径611b和612b。在图6B中，配置实用程序为车道/路径识别提供相似的设施，具有车道/路径611b和612b以及车道/路径边界指示符线621b、622b以及623b，对应于其在上面讨论的图6A中的对等部分。在一个实施例中，每个行驶车道/路径可以分成多个更小的部分。这些部分可以通过GUI规定，例如，通过允许在图像种子上覆盖表示部分的线路或其他指示符。在实施例中，覆盖线可以用于辅助自动表征在图像种子内的非线性。图6A示出了一个实例，具有车道/路径部分指示符631a和其他相似的未标记的车道/路径部分指示符。配置实用程序可以被配置为根据先前规定的车道/路径边界指示符，生成建议的车道/路径部分指示符，并且通过GUI提供工具来根据需要调整车道/路径边界指示符。而且，包括车辆图像(例如，在图6A中显示的车辆A、B以及C)，可以帮助技术人员精确地放置或调整车道/路径部分指示符。图6B显示了车道/路径部分指示符631b以及其他相似的未标记的车道/路径部分指示符，对应于其在上面讨论的图6A中的对等部分。配置实用程序还可以通过GUI提供相似的特征，用于规定图像流的区域，其与第二图像流的各自区域具有重叠的视场。由于这些区域用于将车辆的检测从一个跟踪摄像头“切换”到另一个跟踪摄像头，这些区域可以称为“切换区域”。例如，图6A和6B显示了由具有重叠的视场的摄像头捕捉的图像，其中，切换区域640a的视场与切换区域640b的视场重叠。GUI可以被配置为允许规定在图6A中的切换边界指示符651a和652a以及在图6B中的各种的切换边界 指示符651b和652b。而且，规定的切换区域可以使用在图6A和6B中显示的切换部分指示符611a和611b(以及其他未标记的切换部分指示符)来分成多个更小的部分。配置实用程序可以被配置为根据先前规定的切换边界指示符自动生成建议的切换部分指示符，并且通过GUI提供工具来根据需要调整切换边界指示符。而且，包括车辆图像(例如，在图6A中显示的车辆A、B以及C)，可以帮助技术人员精确地放置或调整切换部分指示符。在实施例中，配置实用程序可以被配置为确定在切换边界指示符651a与652a之间的距离，当这个距离低于最小的期望距离时，警告GUI的用户。虽然在图6A和6B中显示的GUI显示和描述了以简单线条作为由GUI提供的指示符，但是配置实用程序和GUI还可以规定具有更复杂的形状的特征，例如但不限于曲线和手绘线。而且，规定的与第一摄像头相关的指示符(例如，车道/路径边界指示符623a)具有对等的与另一个摄像头相关的指示符(例如，车道/路径边界指示符623b)，这些对等的指示符可以使用GUI连接。在实施例中，可以根据以下信息自动确定或建议这种连接：先前规定的指示符、摄像头的已知位置、摄像头的已知方向、以及最接近摄像头的交通流量的已知方面等信息(例如，车道/路径的数量以及在那些车道/路径内的交通流量的方向)。在实施例中，在摄像头提供变焦和/或摇摄/倾斜功能的情况下，配置实用程序可以被配置为允许通过各种缩放水平或方向在由摄像头捕捉的图像内规定各种指示符特征。这个额外信息可以用于更完整地规定摄像头的总体视场。一旦技术人员对指示符和/或标尺用于规定摄像头的视场满意，这个信息和/或源自该信息的其他信息可以保存在数据库141内，用于(例如)由服务器系统140进行车辆跟踪。配置实用程序可以被配置为提供GUI，以执行连续的摄影机对准。可以通过包含在上述GUI内的额外的用户界面元素，提供这个功能，用于规定车道/路径边界。连续的摄影机对准指的是：在初始摄像头硬件安装过程中、或者如果稍后更新现有摄像头硬件、如果摄像头装有摇摄、倾斜和/或变焦(PTZ)功能，那么需要调整和/或校准摄像头的摇摄、倾斜和/或变焦设置，以确保在摄像 头之间的视场内具有充分重叠，例如，在图4、6A以及6B中显示的重叠。技术人员可以审查GUI以确定一对摄像头是否提供了具有足够尺寸和/或持续时间的切换区域。如果没有提供，那么摇摄、倾斜和/或变焦设置可能需要变化，或者摄像头的物理安装位置可能需要一起改变。配置实用程序可以被配置为提供GUI，以执行目标位置的预先映射，例如，停车位和“非停车”区域。GUI显示了一个图像种子，并且允许技术人员(例如)在图像种子上叠加灰色的多边形。在另一个非限制性实例中，停车位#123可能映射到由特定的目标摄像头通过规定的缩放水平和/或PTZ方向捕捉的20个像素的集合中。GUI可以被配置为提供操作，包括但不限于移动、改变大小、以及旋转这种多边形以表示在摄像头的视场内的目标位置的位置和范围。在摄像头具有PTZ功能的情况下，可以提供PTZ控制。可以通过包含在上述GUI内的额外用户界面元素，提供这个功能，用于规定车道/路径边界。GUI还可以提供将标识符提供给目标位置的界面，例如，该界面可以用于为目标位置提供共同的标识符，用于供服务器系统140的各个方面使用。虽然可以优选地使用配置实用程序或服务器系统140的其他方面来通过最小的直接人工操作来管理、分配和/或修改这种特征，但是GUI还可以提供界面元素，允许规定目标位置的各种特征。在一个实施例中，配置实用程序可以被配置为提供GUI，如上面所讨论的，通过与以上描述的预先映射单车辆目标位置的几乎相同的方式，执行多车辆目标位置的预先映射。配置实用程序可以被配置为允许多个目标位置或多车辆目标位置聚合到单个目标位置内。例如，每个构成目标位置可被分配共同的标识符，以表示其形成多车辆目标位置。配置实用程序可以被配置为允许受限目标位置覆盖多车辆目标位置，“开拓”经受停车限制的广泛区域部分，例如但不限于装卸区和车道。配置实用程序可以被配置为提供GUI，用于规定构成违规停车的内容。在第一实例中，可以给GUI规定宽限期持续时间，在车辆被视为违反对目标位置的使用的限制之前，该持续时间限定车辆可以占据目标位置的时间量。例如， 在车辆停在停车计时表处时，合理地提供宽限期，其足以使车辆的驾驶员离开车辆并且支付停车费。可以给不同类型或组的目标位置(例如，“非停车”区域可以具有小或零宽限期)规定不同的时间段。在第二实例中，可以给GUI规定车辆重叠的量，关于在车辆被视为违规之前车辆覆盖目标位置的建筑面积或区域覆盖百分比的量。在第三实例中，可以使用GUI规定允许停车的规则，包括(例如)与残疾人停车位、居民专用停车位、或需要显示许可证或贴花的其他停车位的使用相关的规则。GUI还可以提供界面，用于识别所需要的许可证或贴花的特征和特性，例如但不限于：颜色、许可证或贴花上具有特色的图像、以及用于许可证或贴花的标识符(例如，序号)的位置。在第四实例中，GUI可以被配置为限定规则，用于确定构成到期的牌照标签的内容，例如，表示当前月份的标签是否被视为到期。配置实用程序可以被配置为提供GUI，用于规定车辆错误使用目标位置的后果。实例包括但不限于：在屏幕上显示车牌照信息、车牌照查找以获得登记持有人的姓名和地址、派遣执法警员来提供错误使用目标位置的车辆的基于激光的照明、将停车罚款应用于存档的信用卡或账户、以及从支票或其他货币账户中扣除停车罚款。配置实用程序可以被配置为接收和记录规定某些车辆的参数，修改检测的违规停车的结果(例如，可以确定警车免除规定的违规)。例如，这种车辆可以由车牌照号识别或者具有指定的标识符(例如，贴花)。在实施例中，服务器系统140可以被配置为获得先存街道和/或停车信息，可以通过商用或市级数据库获得和/或由停车场经营者提供，并且自动确定目标和/或行驶车道/路径信息。在实施例中，根据表示各种识别和目标摄像头的位置和方向的信息，服务器系统140可以被配置为自动预先映射目标位置和/或行驶车道/路径。在实施例中，服务器系统140可以被配置为记录和/或更新在数据库141内记录的目标位置和/或行驶车道/路径的特征，例如但不限于：标识符、位置(例如，纬度/经度或街道地址)、目标位置的使用费用、以及在本申请中描述的用于目标位置的基于时间的、基于日期的以及其他限制。在实施例中，服 务器系统140可以提供API，以更容易地允许停车提供商大量上传目标位置信息和/或更新。在一个替换的实施例中，服务器系统140和在图1中显示的其他部件具有成套平台的形式，其中，不需要通过API与第三方停车支付系统整合。在这种实施例中，成套平台的部分包括支付站/设备以及生成要邮寄的违规停车罚款单的设备。在实施例中，现场支付系统160可以包括成套平台的手机付费功能。最终结果是终端用户可以通过呼叫特定的IVP(交互式语音应答)系统驱动的电话线来支付停车，并且输入目标位置标识符或车牌号以及停车的持续时间，无论目标位置是否与路边的停车计时器、空间付费停车位或停车场相关联。成套手机付费模块能够允许终端用户使用电话(通常是手机)来支付停车费。成套电话付费机器能够与服务器系统140进行数据库等级的整合。数据库等级的整合优于API等级的整合，这是因为数据库等级的整合提供更大的灵活性和速度。成套手机付费模块从一个或多个DTMF收发器中接收数据，其中，用户通过电话输入信息。不要求成套手机付费模块从服务器系统140中接收数据，以便成套手机付费模块正确地操作。成套手机付费模块可以被配置为将数据输出给移动装置150，用于人工支付的停车验证，并且输出给服务器系统140，用于自我执行。在服务器系统140上进行所有自我执行数据处理。在实施例中，现场支付系统160可以包括在成套平台上的在线支付。最终结果是终端用户可以通过访问网站来支付停车费或者查看先前历史，并且输入目标位置标识符或车牌号以及停车的持续时间，无论目标位置是否与路边的停车计时器、空间付费停车位或停车场相关联。这扩展为其他在线渠道，例如，智能电话、以及未来汽车内互联网驱动的媒体中心。成套在线支付模块接收在线数据，其中，终端用户通过互联网输入信息。不要求成套在线支付模块从服务器系统140中接收数据，以便成套在线支付模块正确地操作。成套在线支付模块将数据输出给移动装置150，用于人工支付 的停车验证，并且输出给服务器系统140，用于自我执行。在服务器系统140上进行所有自我执行数据处理。在实施例中，现场支付系统160可以包括具有QR代码的凭票泊车机器。QR代码变得普遍，因此，具有大量智能电话支持。而且，QR代码可以容易地保持通常包含在凭票泊车票据上的所有相关信息(例如但不限于：停车持续时间、停车到期时间、支出金额、日期以及时间)。成套凭票泊车机器允许终端用户支付停车费，并且在车辆的仪表板上留下具有QR代码的泊车票。成套凭票泊车机器能够与服务器系统140进行数据库等级的整合。数据库等级的整合优于API等级的整合，这是因为数据库等级的整合提供更大的灵活性和速度。成套凭票泊车机器通过嵌入式键盘、硬币接收器、信用卡读卡器以及打印机从终端用户中接收付款。还具有文本/图形LCD显示器。不要求成套凭票泊车机器从服务器系统140中接收数据，以便成套凭票泊车机器正确地操作。成套凭票泊车机器将数据输出给移动装置150，用于人工支付的停车验证，并且输出给服务器系统140，用于自我执行。在服务器系统140上进行所有自我执行数据处理。在一个实施例中，现场支付系统160可以包括空间付费成套机器。与具有更长的操作历史的凭票泊车相比，空间付费越来越受欢迎。使用空间付费的停车操作通常更有效，这是因为停车执法人员不再需要走向每辆车并且倾向挡风玻璃内，以便手动检查打印的到期时间。相反，停车执法人员可以驾驶巡逻车，并且从某个距离开始进行肉眼检查，以查看所占据的停车位是否已付费。此外，空间付费提供增强的用户体验，这是因为在通过机器支付之后，驾驶员不再需要走回其车辆中去显示票据，相反，驾驶员可以继续前往其目的地。成套空间付费机器通过嵌入式键盘、硬币接收器、信用卡读卡器以及打印机从终端用户中接收付款。还具有文本/图形LCD显示器。不要求成套空间付费机器从服务器系统140中接收数据，以便成套空间付费机器正确地操作。成套空间付费机器可以将数据输出给移动装置150，用于人工支付的停车验证，并且输出给服务器系统140，用于自我执行。在服务器系统140上进行所有自 我执行数据处理。在一个实施例中，现场支付系统160可以包括牌照付费成套机器。成套牌照付费机器通过嵌入式键盘、硬币接收器、信用卡读卡器以及打印机从终端用户中接收付款。还具有文本/图形LCD显示器。不要求成套牌照付费机器从服务器系统140中接收数据，以便成套牌照付费机器正确地操作。成套牌照付费机器可以将数据输出给移动装置150，用于人工支付的停车验证，并且输出给服务器系统140，用于自我执行。在服务器系统140上进行所有自我执行数据处理。与第三方停车系统整合是一种选项，而不是对服务器系统140的要求。在提供有整个停车设备平台的成套配置中，例如，通过单个供应商提供，不需要与第三方停车系统整合。然而，使用API的整合方法具有很多优点。API提供标准的软件编程接口，其被设计为允许外部程序能够获得主机系统内的信息，而不暴露主机系统的任何商业秘密。这通过在这两个系统的边界产生明确定义的功能、对象以及变量来实现，以便允许外部系统获得预先定义的一组信息，而不了解该信息在主机系统本身内如何搜集、存储或计算。同样，公司通常没有预定其他系统公布API，以与其产品或服务器接合。可以通过API经由基于网络的机构交换数据，通常由加密机构(例如，SSL)保护，依赖于XML、JSON、HTML、MIME或者由API支持的其他编码或语言。服务器系统140具有两种方式来与API整合。首先，通过使用由第三方支付系统公布的API，服务器系统140可以获取车辆支付信息(例如但不限于支付的持续时间以及空间编号)。与服务器系统140已经具有的车辆检测和车辆身份信息相结合，服务器系统140具有或者可以容易地获得为停车设施经营者生成具有详细的违规停车信息的一系列车牌照所需的完整信息，显示详细的违规停车信息。然后，停车设施经营者可以遵循其SOP，并且邮寄违规停车传票，安装车轮固定夹或者拖曳反复或严重的违法者。第二种整合方法是服务器系统140公布其自身的API，因此，第三方支付系统可以获得关于车辆检测和车辆身份的信息。与由第三方支付系统已经具有 的车辆支付信息相结合，第三方支付系统可以向停车场经营者提供无缝显示，包括具有详细的违规停车信息的一系列车牌照。第三方支付系统提供商可以优选这种方法，以便保持控制违规停车信息流回停车场经营者的方式。通过使用API，服务器系统140可以与以下类型的停车支付系统整合：手机付费、空间付费、凭票泊车、路边停车计时表(单或双空间)、以及现场操作人员选项。手机付费的基本前提是终端用户(例如，车辆的驾驶员)呼叫在目标位置附近显示的电话号码。通常，电话号码提供IVR(交互式语音应答)，其通过自动菜单引导呼叫者。提示终端用户驶入唯一目标位置编号，然后，输入期望的停车持续时间、车牌号以及信用卡信息。手机付费开始获得实行，作为流行的“覆盖”支付方法，其中，停车设施经营者将手机付费功能加入路边停车计时表、空间支付以及凭票泊车机器中。典型的动力是为终端用户提供为停车付费的一种替换方法，努力增加停车收入。例如，手机付费可以加入传统的路边停车计时表(单或双空间)中，以便允许终端用户通过手机用信用卡支付。在一个实施例中，服务器系统140可以包括手机付费整合模块，该模块可以是软件元件，该元件第三方停车支付系统中提取停车支付信息，用于服务器系统140的停车自我执行。用于手机付费的整合模块执行步骤，包括：(1)与第三方手机付费API建立连接；(2)发出数据请求；(3)接收数据；(4)处理并且将数据保存到数据库141中；(5)确定违规停车状态；(6)在数据库141内将目标位置的使用标记为违规停车，用于(例如)由下面描述的违规停车预先处理逻辑进一步处理；(7)定期确认第三方手机付费API积极有效，例如但不限于使用“保持激活”/“ping”消息或命令；以及(8)重复步骤2-7或者结束连接。关于步骤(1)，API通常规定机制，通过该机制，可以与其建立连接。手机付费整合模块被配置为观察由第三方手机付费API要求的协议并建立连接。关于步骤(2)，在服务器系统140确定特定的车辆腾出了目标位置时，服 务器系统140用信号将这个事件传送给手机付费整合模块，例如，通过数据库或进程间通信(IPC)呼叫，响应于该呼叫，手机付费整合模块向第三方手机付费API发出请求，请求用于特定车辆的停车支付信息。发送给第三方手机付费API的数据可以包括(例如)：车牌照信息(包括车牌号和州/省信息)、用于由手机付费API识别的目标位置的标识符(其可以请求从由服务器系统140在内部使用的标识符转化)、以及特定车辆腾出目标位置的日期/时间。关于步骤(3)，手机付费整合模块可以被配置为从第三方手机付费API中接收信息，包括(例如)支付的停车开始日期/时间以及支付的停车结束日期/时间。关于步骤(5)，手机付费整合模块可以被配置为将由步骤(3)中接收的数据指示的支付的停车的持续时间与由服务器系统140确定的实际停车持续时间进行比较。如果实际停车持续时间超过支付的停车持续时间，那么执行步骤(6)，否则，不执行步骤(6)。在由服务器系统140提供的API用于整合的实施例中，手机付费系统仅仅从服务器系统140中获得车辆检测信息(实际的车辆停车开始和结束时间)，这是因为车牌照信息通常已经由手机付费系统处理。最终结果是手机付费系统具有生成具有违规停车细节的一系列车牌照所需要的精确信息。通常，在手机付费系统或其成员同意使用由服务器系统140提供的API时，手机付费系统或其成员准备进行某种程度的定制软件开发，通常用于从服务器系统140中接收一些有用的数据。在这个特定的情况下，有用的数据是实际的车辆停车持续时间，表示特定的车辆占据了特定的目标位置的实际时间量、特定的车牌照号或目标位置编号。通常，手机付费系统已经具有车辆牌照号或目标位置编号，这是因为这些信息通常作为终端用户支付流程的一部分而被获取。根据两个选项中的一个，可以通过由服务器系统140提供的手机付费API整合。第一选项是数据流入模型，其中，第三方停车支付系统将信息推送入服务器系统140内。第二选项是数据流出模型，其中，服务器系统140向手机付费系统推送所有相关信息。在一个实施例中，服务器系统140可以包括基于流入的手机付费API，用 于供第三方停车支付系统通过(例如)网络110进行使用，其中，第三方停车支付系统通过基于流入的手机付费API将信息推送入服务器系统140内。基于流入的手机付费API可以被配置为执行步骤，例如，包括：(1)等待第三方停车支付系统建立连接；(2)验证第三方停车支付系统的身份；(3)从第三方停车支付系统中接收数据；(4)处理并将数据存储到数据库141中；(5)确定违规停车状态；(6)在数据库141内将目标位置的使用标记为违规停车，用于(例如)由下面描述的违规停车预先处理逻辑作进一步处理；(7)定期确认基于流入的手机付费API积极有效，例如但不限于使用“保持激活”/“ping”消息或命令；以及(8)在请求时或者在超时时，结束连接。关于步骤(1)，这可以涉及收听第三方停车支付系统的TCP或UDP端口，以建立连接。关于步骤(2)，在允许数据交换之前，要求第三方停车支付系统通过基于流入的手机付费API验证其本身。如果验证失败，那么可以提供重试机制，并且在几次尝试失败后，可以放弃连接。关于步骤(3)，服务器系统140可以被配置为每当车辆/驾驶员支付停车费时，通过基于流入的手机付费API从第三方停车支付系统接收车辆停车信息。所接收的特定车辆的信息可以包括：例如，车牌照信息(包括车牌号和州/省信息)、为特定车辆支付的目标位置的标识符(其可以请求转化成由服务器系统140在内部使用的标识符)、支付的停车开始日期/时间、以及支付的停车结束日期/时间。关于步骤(5)，包含在服务器系统140内的手机付费整合模块可以被配置为将在步骤(3)中接收的数据指示的支付的停车的持续时间与由服务器系统140确定的实际停车持续时间进行比较。如果实际停车持续时间超过支付的停车持续时间，那么执行步骤(6)，否则，不执行步骤(6)。在一个实施例中，服务器系统140可以包括基于流出的手机付费API，用于供第三方停车支付系统通过(例如)网络110进行使用，其中，服务器系统140将所有相关的信息推送至第三方停车支付系统。基于流出的手机付费API可以被配置为执行步骤，例如，包括：(1)等待第三方停车支付系统建立连接；(2)验证第三方停车支付系统的身份；(3)将数据上传给第三方停车支付系统；(4)接收上传的数据的确认；(5)响应于第三方停车支付系统的“保持激活” /“ping”请求；以及(6)在请求时或者在超时时，结束连接。关于步骤(1)，这可以涉及收听第三方停车支付系统的TCP或UDP端口，以建立连接。关于步骤(2)，在允许数据交换之前，要求第三方停车支付系统通过基于流出的手机付费API验证其本身。如果验证失败，那么可以提供重试机制，并且在几次尝试失败后，可以放弃连接。关于步骤(3)，服务器系统140可以被配置为每当车辆腾出与第三方停车支付系统相关联的目标位置时，通过基于流出的手机付费API将车辆停车信息上传给第三方停车支付系统。特定车辆的上传信息可以包括：例如，车牌照信息(包括车牌号和州/省信息)、由第三方停车支付系统识别的目标位置的标识符(其可以请求从由服务器系统140在内部使用的标识符转化)、特定车辆开始使用目标位置的实际日期/时间、以及特定车辆腾出目标位置的实际日期/时间。在另一个实施例中，在手机付费系统与服务器系统140之间通过两个步骤发生整合。首先，服务器系统140使用手机付费系统提供的API，从手机付费系统中获得车辆支付信息(例如，支付的停车开始和结束时间、停车位编号、车牌照号)。在这个阶段，服务器系统140具有生成具有违规停车细节的一系列车牌照所需要的精确信息。然而，服务器系统140并未将这个列表显示给停车场经营者，可以具有以下情况：现有停车支付供应商希望保持控制违规停车信息流回停车场经营者的方式。这可以通过使用由服务器系统140提供的API将违规车辆数据发送回手机付费系统来实现。然后，手机付费系统全面控制将这系列“违法”车辆显示给停车场经营者的方式(例如，通过由手机付费系统供应商开发的定制软件应用程序)。这个整合方法与仅仅依赖于通过由服务器系统140提供的API的整合之间的显著差异在于，这个整合方法要求在手机付费系统供应商部分上具有最小的开发工作。由于已经由服务器系统140提供的API供应要显示给停车场经营者的所有关键信息，无需任何进一步分析，利用最小的软件开发，可以将这个信息简单地显示或转发给停车场经营者。这种整合方法表示在“拉入”之后“推送”的模式。空间付费的前提在于，一旦终端用户停放车辆，终端用户就记录停车位的空间编号。终端用户通过空间付费机器支付停车费时，终端用户输入停车编号，然后输入期望的停车持续时间。一旦支付完成，终端用户不需要在车辆内留下票据，而是可以继续到他们想去的地方。空间付费同样有利于在街道上路边停车和街外停车场/停车库。与具有更长的操作历史的凭票泊车相比，空间付费越来越受欢迎。使用空间付费的停车操作通常更有效，这是因为停车执法人员不再需要走向每辆车并且倾向挡风玻璃内，以便手动检查打印的到期时间。相反，停车执法人员可以驾驶巡逻车，并且从某个距离开始进行肉眼检查，以查看所占据的停车位是否已付费。此外，空间付费提供增强的用户体验，这是因为在通过机器支付之后，驾驶员不再需要走回其车辆中去显示票据，而是可以继续前往其目的地。与上述手机付费相似，通过使用空间付费系统提供的API或者由服务器系统140提供的API，可以实现整合。目标在于，任一个系统可获取生成具有违规停车信息的一系列车牌照所需要的所有信息。在服务器系统140通过空间付费系统提供的API整合的一个实施例中，服务器系统140从空间付费系统中获得车辆支付信息(例如，支付的停车开始和结束时间、目标位置编号以及车牌照号)。最终结果是，服务器系统140具有生成具有违规停车细节的一系列车牌照所需要的精确信息。在一个实施例中，服务器系统140可以包括空间付费整合模块，该模块可以是软件元件，该元件从服务器系统140用于停车自我执行的第三方停车支付系统中提取停车支付信息。用于空间付费的整合模块执行步骤，包括：(1)与第三方空间付费API建立连接；(2)发出数据请求；(3)接收数据；(4)处理并将数据存储到数据库141中；(5)确定违规停车状态；(6)在数据库141内将目标位置的使用标记为违规停车，用于(例如)由下面描述的违规停车预先处理逻辑进一步处理；(7)定期确认第三方空间付费API积极有效，例如但不限于使用“保持激活”/“ping”消息或命令；以及(8)重复步骤2-7或者结束连接。关于步骤(1)，API通常规定机制，通过该机制，可以与其建立连接。 空间付费整合模块被配置为观察由第三方空间付费API要求的协议并且建立连接。关于步骤(2)，在服务器系统140确定特定的车辆腾出了目标位置时，服务器系统140用信号将这个事件传送给空间付费整合模块，例如，通过数据库或进程间通信(IPC)呼叫，响应于该呼叫，空间付费整合模块给第三方空间付费API发出请求，请求特定车辆的停车支付信息。发送给第三方空间付费API的数据可以包括：例如，用于由空间付费API识别的目标位置的标识符(其可以请求从由服务器系统140在内部使用的标识符转化)、以及特定车辆腾出目标位置的日期/时间。关于步骤(3)，空间付费整合模块可以被配置为从第三方空间付费API中接收信息，包括：例如，支付的停车开始日期/时间、以及支付的停车结束日期/时间。关于步骤(5)，空间付费整合模块可以被配置为将由从步骤(3)中接收的数据指示的支付的停车的持续时间与由服务器系统140确定的实际停车持续时间进行比较。如果实际停车持续时间超过支付的停车持续时间，那么执行步骤(6)，否则，不执行步骤(6)。在服务器系统140通过由服务器系统140提供的API与空间付费系统整合的实施例中，服务器系统140将车辆信息传输给空间付费系统(例如，车牌照号、目标位置、以及实际的停车开始和结束时间)。最终结果是空间付费系统具有生成具有违规停车细节的一系列车牌照所需要的精确信息。通常，在空间付费系统或其成员同意使用由服务器系统140提供的API时，空间付费系统或其成员准备进行某种程度的定制软件开发，通常用于从服务器系统140中接收一些有用的数据。在这个特定的情况下，有用的数据是实际的车辆停车持续时间，特定的车辆占据了特定的目标位置的实际时间量、特定的车牌照号或车位编号。通常，空间付费系统已经具有车辆牌照号或车位编号，这是因为这些信息通常作为终端用户支付流程的一部分而被获取。根据两个选项中的一个，可以通过由服务器系统140提供的空间付费API整合。第一选项是数据流入模型，其中，第三方停车支付系统将信息推送入服 务器系统140内。第二选项是数据流出模型，其中，服务器系统140向空间付费系统推送所有相关信息。在一个实施例中，服务器系统140可以包括基于流入的空间付费API，用于供第三方停车支付系统通过(例如)网络110进行使用，其中，第三方停车支付系统通过基于流入的空间付费API将信息推送入服务器系统140内。基于流入的空间付费API可以被配置为执行步骤，例如，包括：(1)等待第三方停车支付系统建立连接；(2)验证第三方停车支付系统的身份；(3)从第三方停车支付系统中接收数据；(4)处理并将数据存储到数据库141中；(5)确定违规停车状态；(6)在数据库141内将目标位置的使用标记为违规停车，用于(例如)由下面描述的违规停车预先处理逻辑作进一步处理；(7)定期确认基于流入的空间付费API积极有效，例如但不限于使用“保持激活”/“ping”消息或命令；以及(8)在请求时或者在超时时，结束连接。关于步骤(1)，这可以涉及收听第三方停车支付系统的TCP或UDP端口，以建立连接。关于步骤(2)，在允许数据交换之前，要求第三方停车支付系统通过基于流入的空间付费API验证其本身。如果验证失败，那么可以提供重试机制，并且在几次尝试失败后，可以放弃连接。关于步骤(3)，服务器系统140可以被配置为每当车辆/驾驶员支付停车费时，通过基于流入的空间付费API从第三方停车支付系统接收车辆停车信息。所接收的特定车辆的信息可以包括：例如，为特定车辆支付的目标位置的标识符(其可以请求转化成由服务器系统140在内部使用的标识符)、支付的停车开始日期/时间、以及支付的停车结束日期/时间。关于步骤(5)，包含在服务器系统140内的空间付费整合模块可以被配置为将由从步骤(3)中接收的数据指示的支付的停车的持续时间与由服务器系统140确定的实际停车持续时间进行比较。如果实际停车持续时间超过支付的停车持续时间，那么执行步骤(6)，否则，不执行步骤(6)。在一个实施例中，服务器系统140可以包括基于流出的空间付费API，用于供第三方停车支付系统通过(例如)网络110进行使用，其中，服务器系统140将所有相关的信息推送至第三方停车支付系统。基于流出的空间付费API 可以被配置为执行步骤，例如，包括：(1)等待第三方停车支付系统建立连接；(2)验证第三方停车支付系统的身份；(3)将数据上传给第三方停车支付系统；(4)接收上传的数据的确认；(5)响应于第三方停车支付系统的“保持激活”/“ping”请求；以及(6)在请求时或者在超时时，结束连接。关于步骤(1)，这可以涉及收听第三方停车支付系统的TCP或UDP端口，以建立连接。关于步骤(2)，在允许数据交换之前，要求第三方停车支付系统通过基于流出的空间付费API验证其本身。如果验证失败，那么可以提供重试机制，并且在几次尝试失败后，可以放弃连接。关于步骤(3)，服务器系统140可以被配置为每当车辆腾出与第三方停车支付系统相关联的目标位置时，通过基于流出的空间付费API将车辆停车信息上传给第三方停车支付系统。特定车辆的上传信息可以包括：例如，车牌照信息(包括车牌号和州/省信息)、由第三方停车支付系统识别的目标位置的标识符(其可以请求从由服务器系统140在内部使用的标识符转化)、特定车辆开始使用目标位置的实际日期/时间以及特定车辆腾出目标位置的实际日期/时间。在另一个实施例中，服务器系统140被配置为通过两个步骤与空间付费系统整合。首先，服务器系统140使用空间付费系统提供的API，从空间付费系统获得车辆支付信息(例如，支付的停车开始和结束时间、停车位编号、车牌照号)。在这个阶段，服务器系统140具有生成具有违规停车细节的一系列车牌照所需要的精确信息。然而，服务器系统140并未将这个列表显示给停车场经营者，可以具有以下情况：现有停车支付供应商希望保持控制违规停车信息流回停车场经营者的方式。这可以通过使用由服务器系统140提供的API将违规车辆数据发送回空间付费系统来实现。然后，空间付费系统全面控制将这系列“违法”车辆显示给停车场经营者的方式(例如，通过由空间付费系统供应商开发的定制软件应用程序)。在这个整合方法与通过由服务器系统140提供的API的与空间付费系统整合之间的显著差异在于，这个整合方法要求在空间付费系统供应商部分上具有最小的开发工作。由于已经由服务器系统140提供的API供应要显示给停车场 经营者的所有关键信息，无需任何进一步分析，利用最小的软件开发，可以将这个信息简单地显示或转发给停车场经营者。这种整合方法表示在“拉入”之后“推送”的模式。凭票泊车的前提在于，一旦终端用户支付了停车费，终端用户就需要在车辆内部仪表板上留下票据，以便停车执法人员进行票据的肉眼检查，以确保终端用户付费的时间段未到期。从历史的观点上说，凭票泊车控制街外停车场和停车库。尽管最近流行空间付费机器，但是凭票泊车依然具有广阔的安装基础。依然有为路边停车部署的凭票泊车系统。为了提供自我执行功能，服务器系统140需要以下信息：车牌照信息(包括州/省)、实际的停车开始和结束时间、支付的停车持续时间。在整合服务器系统140和凭票泊车系统的实施例中，服务器系统140通过识别摄像头采集车牌照信息，而通过允许服务器系统140确定车辆进入目标位置内的时间以及车辆离开的时间，目标摄像头提供实际的停车开始和结束时间。通过使用具有摇摄、倾斜和变焦功能的目标摄像头，进行放大，以从终端用户放在车辆仪表板上的泊车票本身中提取条形码或打印的字符，来确定支付的停车持续时间。在实施例中，为了方便读取这种信息，凭票泊车机器可以被配置为将更大的字体用于打印的字符中，或者打印更大版本的其他识别特征。在另一个实施例中，凭票泊车机器可以被配置为请求车牌号，作为支付流程的一部分，而传统的系统仅仅询问驾驶员希望停放车辆的时间量。在实施例中，凭票泊车机器可以使用几卷纸质泊车票，RFID芯片嵌入每个泊车票内。在实施例中，服务器系统140可以被配置为根据通过一个或多个摄像头捕捉的多个图像进行行人跟踪，例如，在其视场内包括凭票泊车机器的摄像头。通过行人跟踪，服务器系统140可以被配置为在车辆的驾驶员和/或乘客走向车辆和/或从车辆中走出时，跟踪他们，通过凭票泊车机器对该车辆进行支付，与服务器系统140进行车辆跟踪时几乎一样。根据跟踪的行人运动，可以将支付 与车辆的特定位置以及由服务器系统140确定的相应车辆标识符(例如，车牌号)联系。这种实施例不需要直接从打印的票据中捕捉信息。在一个实例中，服务器系统140可以接收由一个或多个摄像头捕捉的多个行人图像，包括表明个人是车辆的乘客的一个或多个图像以及表明乘客为了使用目标位置在凭票泊车支付站中进行支付的一个或多个图像。服务器系统140可以被配置为通过确定为在行人图像中捕捉的行人确定的特征是否随着时间对应，来进行跟踪，显示乘客在车辆与支付站之间行进并且进行支付。基于这一点，服务器系统140可以使支付与车辆的特定目标位置的使用相关联。有了以上信息，服务器系统140能够产生具有详细的违规信息的一系列车牌照。由于凭票泊车系统本身没有任何所述信息，所以无论凭票泊车系统是否支持实时无线网络，都是如此。在通过由服务器系统140提供的API整合服务器系统140和凭票泊车系统的实施例中，为了提供自我执行功能，服务器系统140需要车牌照信息(包括州/省)、实际的停车开始和结束时间、以及支付的停车持续时间。服务器系统140通过识别摄像头采集车牌照信息，而通过检测车辆进入停车位内的时间以及车辆离开的时间，目标摄像头使服务器系统140能够确定实际的停车开始和结束时间。通过使用具有摇摄、倾斜和/或变焦功能的目标摄像头，进行放大，以从终端用户放在车辆仪表板上的泊车票本身中提取条形码或打印的字符，来确定支付的停车持续时间。由服务器系统140提供的凭票泊车API可以被配置为执行步骤，例如，包括：(1)等待第三方停车支付系统建立连接；(2)验证第三方停车支付系统的身份；(3)将数据上传给第三方停车支付系统；(4)接收上传的数据的确认；(5)响应于第三方停车支付系统的“保持激活”/“ping”请求；以及(6)在请求时或者在超时时，结束连接。关于步骤(1)，这可以涉及收听第三方停车支付系统的TCP或UDP端口，以建立连接。关于步骤(2)，在允许数据交换之前，要求第三方停车支付系统通过凭票泊车API验证其本身。如果验证失败，那么可以提供重试机制，并且在几次尝试失败后，可以放弃连接。关于步骤(3)， 服务器系统140可以被配置为每当车辆腾出与第三方停车支付系统相关联的目标位置时，通过凭票泊车API，将车辆停车信息上传给第三方停车支付系统。特定车辆的上传信息可以包括：例如，车牌照信息(包括车牌号和州/省信息)、由第三方停车支付系统识别的目标位置的标识符(其可以请求从由服务器系统140在内部使用的标识符转化)、特定车辆开始使用目标位置的实际日期/时间以及特定车辆腾出目标位置的实际日期/时间。在服务器系统140被配置为在这种模式下操作时，服务器系统140将车辆违规停车信息传输给凭票泊车系统(例如，车牌照号、支付的停车开始和结束时间、以及实际的停车开始和结束时间)。最终结果是第三方凭票泊车系统具有生成具有违规停车细节的一系列车牌照所需要的精确信息。通常，在凭票泊车系统或其成员同意使用由服务器系统140提供的API时，凭票泊车系统或其成员准备进行某种程度的定制软件开发，通常用于从服务器系统140中接收一些有用的数据。在这个特定的情况下，有用的数据是用于特定的车牌照号的支付的停车开始和结束时间以及实际的车辆停车开始和结束时间。通常，凭票泊车系统是纸质(因为这些系统依赖于打印的泊车票)并且不具有与车辆身份或目标位置编号相关的任何信息。虽然凭票泊车系统具有付费停车开始时间和支付的停车持续时间，但是这些系统不了解支付的停车与哪个车辆相关联。凭票泊车系统可以选择通过使用由服务器系统140提供的API来将具有违规停车信息的一系列车辆显示给停车场经营者。通过API，凭票泊车系统可以从服务器系统140中获得相关信息并以任何需要的格式显示该信息。同样，通过由服务器系统140提供的API的整合是“推送”模式，其中，服务器系统140将所有相关信息“推送”给凭票泊车系统。然后，凭票泊车系统显示未付费或到期停车的一系列车牌照。换言之，通过由服务器系统140提供的API的凭票泊车整合通常不是在“拉入”模式中完成。在实施例中，可以提供具有QR代码的凭票泊车机器。QR代码变得普遍，并且可以容易地保持通常包含在凭票泊车票据上的所有相关信息(例如，停车持续时间、停车到期时间、支出金额、日期以及时间)。在实施例中，手机付费系统可以覆盖凭票泊车系统，并且服务器系统140可以通过API与手机付费系统整合。在这种情况下，在使用手机付费系统提供的API时，服务器系统140将车辆检测信息传输给手机付费系统，这是因为通常，手机付费系统已经具有了车牌照信息。最终结果是手机付费系统具有生成具有违规停车细节的一系列车牌照所需要的信息。虽然传统的路边停车计时表(单或双空间)仅仅接受硬币，没有嵌入式智能或网络功能，但是手机付费系统变成了受欢迎的“覆盖”支付方法，该方法可以很好地与传统的路边停车计时表合作。近来，还出现了接受硬币和信用卡并且具有嵌入的网络功能的路边停车计时表。传统的停车计时表通常具有机械或LCD显示器“到期标记”，以表示支付的停车时间段到期或者未付费停车。在支付了停车并且具有剩余时间时，机械到期标记(通常是红色)隐藏，然而，LCD显示器在计时表朝着道路的一侧显示了清晰显示。相反，在付费停车到期或者未付费时，在“上部”位置中明显地显示红色机械到期标记，而朝着道路的LCD显示器在清晰显示与暗场显示之间交替地闪光(有时也通过红闪光LED)。这两个通常都称为到期标记。在一个实施例中，服务器系统140可以使用从识别和目标摄像头中采集的信息组合来与传统的路边停车计时表接合。除了识别车辆停车状态(例如但不限于停车开始和结束时间)以外，由识别和目标摄像头捕捉的图像可以在停车计时表上准确地找出付费停车状态(例如但不限于预先付费的时间是否到期)。服务器系统140通过由识别摄像头捕捉的图像采集车牌照信息，而由目标摄像头捕捉的图像使服务器系统140能够通过检测车辆驶入停车位的时间以及车辆离开的时间来确定实际的停车开始和结束时间。通过使用位置和目标摄像头来放大并且监控在每个停车计时表上的到期标记的可见状态，确定付费停车的到期时间。根据这个信息，服务器系统140可以确定违规停车状态，并且在数据库141内将目标位置的使用标记为违规停车，用于(例如)由下面描述的违规停车预先处理逻辑作进一步处理。在服务器系统140不可读取到期标记的情况下，服务器系统140可以被配置为向停车场经营者或成员指示异常和/或利 用现场操作人员(下面讨论的)，以手动确定违规停车状态和/或异常标记状态。由目标摄像头从街道对面捕捉的目标图像具有充足的视角，来监控每个停车计时表上到期标记的状态。此外，具有摇摄、倾斜以及变焦功能的识别摄像头可以具有充足的变焦功率和视角，以便也监控每个停车计时表上到期标记的状态。通过以上可用的信息，服务器系统140能够产生具有详细的违规信息的一系列车牌照。在一个实施例中，通过由服务器系统140提供的API整合服务器系统140和传统的路边停车计时表系统，以提供自我执行功能，服务器系统140需要车牌照信息(包括州/省信息)、实际的停车开始和结束时间、以及支付的停车持续时间。服务器系统140通过由识别摄像头捕捉的图像采集车牌照信息，而由目标摄像头捕捉的图像使服务器系统140能够通过检测车辆驶入停车位的时间以及车辆离开的时间来确定实际的停车开始和结束时间。通过使用位置和目标摄像头来放大并且监控在每个停车计时表上的到期标记的可见状态，确定支付的停车的到期时间。根据这个信息，服务器系统140可以确定违规停车状态，并且在数据库141内将目标位置的使用标记为违规停车，用于(例如)由下面描述的违规停车预先处理逻辑作进一步处理。在服务器系统140不可读取到期标记的情况下，服务器系统140可以被配置为向停车场经营者或成员指示异常和/或利用现场操作人员(下面讨论的)，以手动确定违规停车状态和/或异常标记状态。由服务器系统140提供的传统的路边停车计时表API可以被配置为执行步骤，例如，包括：(1)等待第三方停车支付系统建立连接；(2)验证第三方停车支付系统的身份；(3)将数据上传给第三方停车支付系统；(4)接收上传的数据的确认；(5)响应于第三方停车支付系统的“保持激活”/“ping”请求；以及(6)在请求时或者在超时时，结束连接。关于步骤(1)，这可以涉及收听第三方停车支付系统的TCP或UDP端口，以建立连接。关于步骤(2)，在允许数据交换之前，要求第三方停车支付系统通过传统的路边停车计时表API验 证其本身。如果验证失败，那么可以提供重试机制，并且在几次尝试失败后，可以放弃连接。关于步骤(3)，服务器系统140可以被配置为每当车辆腾出与第三方停车支付系统相关联的目标位置时，通过传统的路边停车计时表API，将车辆停车信息上传给第三方停车支付系统。特定车辆的上传信息可以包括：例如，车牌照信息(包括车牌号和州/省信息)、由第三方停车支付系统识别的目标位置的标识符(其可以请求从由服务器系统140在内部使用的标识符转化)、特定车辆开始使用目标位置的实际日期/时间、以及特定车辆腾出目标位置的实际日期/时间。在服务器系统140被配置为在这种模式下操作时，服务器系统140将车辆违规停车信息传输给传统的路边停车计时表系统，这通常是不与实际的路边计时表连接的支付收取/记账系统。最终结果是传统的路边停车计时表系统具有生成具有违规停车细节的一系列车牌照所需要的精确信息。通常，在传统的路边停车计时表系统或其成员同意使用由服务器系统140提供的API时，传统的路边停车计时表系统或其成员准备进行某种程度的定制软件开发，通常用于从服务器系统140中接收一些有用的数据。在这个特定的情况下，有用的数据是用于特定的车牌照号的到期的或未付费的停车状态以及实际的车辆停车开始和结束时间。通常，传统的路边停车计时表系统不具有与车辆身份或车位编号相关的任何信息。同样，通过由服务器系统140提供的API的整合是“推送”模式，其中，服务器系统140将所有相关信息“推送”给传统的路边停车计时表系统。然后，传统的路边停车计时表系统显示未付费或到期停车的一系列车牌照。在实施例中，手机付费系统可以覆盖传统的路边停车计时表系统，并且服务器系统140可以通过API与手机付费系统整合。在这种情况下，在使用手机付费系统提供的API时，服务器系统140将车辆检测信息传输给手机付费系统，这是因为通常，手机付费系统已经具有了车牌照信息。最终结果是手机付费系统具有生成具有违规停车细节的一系列车牌照所需要的信息。最近，推出了路边停车计时表(单或双空间)，其使用嵌入式3G或WiFi 调制解调器执行信用卡授权。在实施例中，服务器系统140可以被配置为通过路边停车计时表API与这种类型的停车计时表接合。具体而言，由于这些路边停车计时表已经具有嵌入式无线网络连接和相关联的后端服务器，所以服务器系统140不难与这个第三方后端服务器整合。在服务器系统140被配置为在这种模式下操作时，用于路边停车计时表API的整合模块执行步骤，包括：(1)与第三方路边停车计时表API建立连接；(2)发出数据请求；(3)接收数据；(4)处理并将数据存储到数据库141中；(5)确定违规停车状态；(6)在数据库141内将目标位置的使用标记为违规停车，用于(例如)由下面描述的违规停车预先处理逻辑作进一步处理；(7)定期确认路边停车计时表API积极有效，例如但不限于使用“保持激活”/“ping”消息或命令；以及(8)重复步骤2-7或者结束连接。关于步骤(1)，API通常规定机制，通过该机制，可以与其建立连接。路边停车计时表API的整合模块被配置为观察由路边停车计时表API要求的协议并建立连接。关于步骤(2)，在服务器系统140确定特定的车辆腾出了目标位置时，服务器系统140用信号将这个事件传送给路边停车计时表API的整合模块，例如，通过数据库或进程间通信(IPC)呼叫，响应于该呼叫，路边停车计时表API的整合模块给第三方路边停车计时表API发出请求，请求特定车辆的停车支付信息。发送给第三方路边停车计时表API的数据可以包括：例如，用于由路边停车计时表API识别的目标位置的标识符(其可以请求从由服务器系统140在内部使用的标识符转化)、以及特定车辆腾出目标位置的日期/时间。关于步骤(3)，路边停车计时表API的整合模块可以被配置为从第三方路边停车计时表API中接收信息，包括：例如，由路边停车计时表API识别的目标位置的标识符(其可以请求转化成由服务器系统140在内部使用的标识符)、支付的停车开始日期/时间、以及支付的停车结束日期/时间。关于步骤(5)，路边停车计时表API的整合模块可以被配置为将由从步骤(3)中接收的数据指示的支付的停车的持续时间与由服务器系统140确定的实际停车持续时间进行比较。如果实际停车持续时间超过支付的停车持续时间，那么执行步骤(6)， 否则，不执行步骤(6)。同样，通过路边停车计时表API的整合是“拉入”模式，其中，服务器系统140“拉入”第三方路边停车计时表系统能够输出的所有相关信息，并且加入由服务器系统140确定的自动车辆违规信息，以产生未付费停车或到期停车的一系列车牌照。换言之，通过路边停车计时表API的整合通常不是在“拉入”模式中完成的。在服务器系统140被配置为通过由服务器系统140提供的API与路边停车计时表系统整合的实施例中，服务器系统140将车辆信息传输给路边停车计时表系统(例如，车牌照号、目标位置、以及实际的车辆停车开始和结束时间)。最终结果是路边停车计时表系统具有生成具有违规停车细节的一系列车牌照所需要的精确信息。通常，在路边停车计时表系统或其成员同意使用由服务器系统140提供的API时，路边停车计时表系统或其成员准备进行某种程度的定制软件开发，通常用于从服务器系统140中接收一些有用的数据。在这个特定的情况下，有用的数据是实际的车辆停车持续时间，针对特定的车牌照号或车位编号，特定的车辆占据特定的目标位置的实际时间量。通常，路边停车计时表系统已经具有车辆牌照号或车位编号，这是因为这些信息通常作为终端用户支付流程的一部分而被获取。根据两个选项中的一个，可以通过由服务器系统140提供的路边停车计时表API整合。第一选项是数据流入模型，其中，第三方停车支付系统将信息推送入服务器系统140内。第二选项是数据流出模型，其中，服务器系统140向路边停车计时表系统推送所有相关信息。在一个实施例中，服务器系统140可以包括基于流入的路边停车计时表API，用于供第三方停车支付系统通过(例如)网络110进行使用，其中，第三方停车支付系统通过基于流入的路边停车计时表API将信息推送入服务器系统140内。基于流入的路边停车计时表API可以被配置为执行步骤，例如，包括：(1)等待第三方停车支付系统建立连接；(2)验证第三方停车支付系统的身份； (3)从第三方停车支付系统中接收数据；(4)处理并将数据存储到数据库141中；(5)确定违规停车状态；(6)在数据库141内将目标位置的使用标记为违规停车，用于(例如)由下面描述的违规停车预先处理逻辑作进一步处理；(7)定期确认基于流入的路边停车计时表API积极有效，例如但不限于使用“保持激活”/“ping”消息或命令；以及(8)在请求时或者在超时时，结束连接。关于步骤(1)，这可以涉及收听第三方停车支付系统的TCP或UDP端口，以建立连接。关于步骤(2)，在允许数据交换之前，要求第三方停车支付系统通过基于流入的路边停车计时表API验证其本身。如果验证失败，那么可以提供重试机制，并且在几次尝试失败后，可以放弃连接。关于步骤(3)，服务器系统140可以被配置为每当车辆/驾驶员支付停车费时，通过基于流入的路边停车计时表API从第三方停车支付系统中接收车辆停车信息。所接收的特定车辆的信息可以包括：例如，为特定车辆支付的目标位置的标识符(其可以请求转化成由服务器系统140在内部使用的标识符)、支付的停车开始日期/时间以及支付的停车结束日期/时间。关于步骤(5)，包含在服务器系统140内的路边停车计时表整合模块可以被配置为将由从步骤(3)中接收的数据所指示的支付的停车的持续时间与由服务器系统140确定的实际停车持续时间进行比较。如果实际停车持续时间超过支付的停车持续时间，那么执行步骤(6)，否则，不执行步骤(6)。在一个实施例中，服务器系统140可以包括基于流出的路边停车计时表API，用于供第三方停车支付系统通过(例如)网络110进行使用，其中，服务器系统140将所有相关的信息推送至第三方停车支付系统。基于流出的路边停车计时表API可以被配置为执行步骤，例如，包括：(1)等待第三方停车支付系统建立连接；(2)验证第三方停车支付系统的身份；(3)将数据上传给第三方停车支付系统；(4)接收上传的数据的确认；(5)响应于第三方停车支付系统的“保持激活”/“ping”请求；以及(6)在请求时或者在超时时，结束连接。关于步骤(1)，这可以涉及收听第三方停车支付系统的TCP或UDP端口，以建立连接。关于步骤(2)，在允许数据交换之前，要求第三方停车支付系统通 过基于流出的路边停车计时表API验证其本身。如果验证失败，那么可以提供重试机制，并且在几次尝试不成功之后，可以放弃连接。关于步骤(3)，服务器系统140可以被配置为每当车辆腾出与第三方停车支付系统相关联的目标位置时，通过基于流出的路边停车计时表API将车辆停车信息上传给第三方停车支付系统。特定车辆的上传信息可以包括：例如，车牌照信息(包括车牌号和州/省信息)、由第三方停车支付系统识别的目标位置的标识符(其可以请求从由服务器系统140在内部使用的标识符转化)、特定车辆开始使用目标位置的实际日期/时间、以及特定车辆腾出目标位置的实际日期/时间。在一个实施例中，服务器系统140可以被配置为通过两个步骤与路边停车计时表系统整合。首先，服务器系统140使用路边停车计时表系统提供的API，从路边停车计时表系统中获得车辆支付信息(例如，支付的停车开始和结束时间、停车位编号、车牌照号)。在这个阶段，服务器系统140具有生成具有违规停车细节的一系列车牌照所需要的精确信息。然而，服务器系统140并未将这个列表显示给停车场经营者，可以具有以下情况：现有停车支付供应商希望保持控制违规停车信息流回停车场经营者的方式。这可以通过使用由服务器系统140提供的API将违规车辆数据发送回路边停车计时表系统来实现。然后，路边停车计时表系统全面控制将这系列“违法”车辆显示给停车场经营者的方式(例如，通过由路边停车计时表系统供应商开发的定制软件应用程序)。在这个整合方法与通过由服务器系统140提供的API的整合之间的显著差异在于，这个整合方法要求在路边停车计时表系统供应商部分上具有最小的开发工作。由于已经由服务器系统140提供的API供应要显示给停车场经营者的所有关键信息，无需任何进一步分析，利用最小的软件开发，可以将这个信息简单地显示或转发给停车场经营者。这种整合方法表示在“拉入”之后“推送”的模式。与停车支付与特定编号的停车位(车辆停车)相关联的空间付费相似，牌照付费使车辆的停车支付与停在停车位内的特定车牌照相关联。牌照付费停车的手工执行通常涉及执法人员驱车穿过物理停车位，以确保所有停放的车辆的 车牌照在具有支付状态的一系列车牌照上。相反，车牌照不在“支付”列表上的所有停放车辆将收到违规停车传票。与上述手机付费和空间付费相似，通过使用牌照付费系统提供的API或者由服务器系统140提供的API，可以实现整合。目标在于，任一个系统可以获得生成具有违规停车信息的一系列车牌照所需要的所有信息。在服务器系统140通过牌照付费系统提供的API整合的实施例中，服务器系统140从牌照付费系统中获得车辆支付信息(例如，支付的停车开始和结束时间、目标位置编号以及车牌照号)。最终结果是，服务器系统140具有生成具有违规停车细节的一系列车牌照所需要的精确信息。在一个实施例中，服务器系统140可以包括牌照付费整合模块，该模块可以是软件元件，该元件从服务器系统140用于停车自我执行的第三方停车支付系统中提取停车支付信息。用于牌照付费的整合模块执行步骤，包括：(1)与第三方牌照付费API建立连接；(2)发出数据请求；(3)接收数据；(4)处理并将数据存储到数据库141中；(5)确定违规停车状态；(6)在数据库141内将目标位置的使用标记为违规停车，用于(例如)由下面描述的违规停车预先处理逻辑作进一步处理；(7)定期确认第三方牌照付费API积极有效，例如但不限于使用“保持激活”/“ping”消息或命令；以及(8)重复步骤2-7或者结束连接。关于步骤(1)，API通常规定机制，通过该机制，可以与其建立连接。牌照付费整合模块被配置为观察由第三方牌照付费API要求的协议并且建立连接。关于步骤(2)，在服务器系统140确定特定的车辆腾出了目标位置时，服务器系统140用信号将这个事件传送给牌照付费整合模块，例如，通过数据库或进程间通信(IPC)呼叫，响应于该呼叫，牌照付费整合模块给第三方牌照付费API发出请求，请求用于特定车辆的停车支付信息。发送给第三方牌照付费API的数据可以包括：例如，车牌照信息(包括车牌编号和州/省信息)以及特定车辆腾出目标位置的日期/时间。关于步骤(3)，牌照付费整合模块可以被配置为从第三方牌照付费API中 接收信息，包括(例如)支付的停车开始日期/时间以及支付的停车结束日期/时间。关于步骤(5)，牌照付费整合模块可以被配置为将由从步骤(3)中接收的数据所指示的支付的停车的持续时间与由服务器系统140确定的实际停车持续时间进行比较。如果实际停车持续时间超过支付的停车持续时间，那么执行步骤(6)，否则，不执行步骤(6)。在服务器系统140通过由服务器系统140提供的API与牌照付费系统整合的实施例中，服务器系统140将车辆信息传输给牌照付费系统(例如，车牌照号、目标位置、以及实际的车辆停车开始和结束时间)。最终结果是牌照付费系统具有生成具有违规停车细节的一系列车牌照所需要的精确信息。通常，在牌照付费系统或其成员同意使用由服务器系统140提供的API时，牌照付费系统或其成员准备进行某种程度的定制软件开发，通常用于从服务器系统140中接收一些有用的数据。在这个特定的情况下，有用的数据是实际的车辆停车持续时间，针对特定的车牌照号，特定的车辆占据特定的目标位置的实际时间量。按照定义，牌照付费系统已经具有车辆牌照号，这是因为这些信息通常作为终端用户支付流程的一部分而被获取。根据两个选项中的一个，可以通过由服务器系统140提供的牌照付费API整合。第一选项是数据流入模型，其中，第三方停车支付系统将信息推送入服务器系统140内。第二选项是数据流出模型，其中，服务器系统140将所有相关信息推送给第三方牌照付费系统。在一个实施例中，服务器系统140可以包括基于流入的牌照付费API，用于供第三方停车支付系统通过(例如)网络110使用，其中，第三方停车支付系统通过基于流入的牌照付费API将信息推入服务器系统140内。基于流入的牌照付费API可以被配置为执行步骤，例如，包括：(1)等待第三方停车支付系统建立连接；(2)验证第三方停车支付系统的身份；(3)从第三方停车支付系统中接收数据；(4)处理并将数据存储到数据库141中；(5)确定违规停车状态；(6)在数据库141内将目标位置的使用标记为违规停车，用于(例如)由下面描述的违规停车预先处理逻辑进一步处理；(7)定期确认基于流入的牌 照付费API积极有效，例如但不限于使用“保持激活”/“ping”消息或命令；以及(8)在请求时或者在超时时，结束连接。关于步骤(1)，这可以涉及收听第三方停车支付系统的TCP或UDP端口，以建立连接。关于步骤(2)，在允许数据交换之前，要求第三方停车支付系统通过基于流入的牌照付费API验证其本身。如果验证失败，那么可以提供重试机制，并且在几次尝试不成功之后，可以放弃连接。关于步骤(3)，服务器系统140可以被配置为每当车辆/驾驶员支付停车费时，通过基于流入的牌照付费API从第三方停车支付系统中接收车辆停车信息。特定车辆的接收信息可以包括(例如)车牌照信息(包括车牌号和州/省信息)、支付的停车开始日期/时间以及支付的停车结束日期/时间。关于步骤(5)，包含在服务器系统140内的牌照付费整合模块可以被配置为比较由从步骤(3)中接收的数据所指示的支付的停车持续时间和由服务器系统140确定的实际停车持续时间。如果实际停车持续时间超过支付的停车持续时间，那么执行步骤(6)的处理，否则，不执行步骤(6)。在一个实施例中，服务器系统140可以包括基于流出的牌照付费API，用于供第三方停车支付系统通过(例如)网络110使用，其中，服务器系统140将所有相关的信息推入第三方牌照付费系统中。基于流出的牌照付费API可以被配置为执行步骤，例如，包括：(1)等待第三方停车支付系统建立连接；(2)验证第三方停车支付系统的身份；(3)将数据上传给第三方停车支付系统；(4)接收上传的数据的确认；(5)响应于第三方停车支付系统的“保持激活”/“ping”请求；以及(6)在请求时或者在超时时，结束连接。关于步骤(1)，这可以涉及收听第三方停车支付系统的TCP或UDP端口，以建立连接。关于步骤(2)，在允许数据交换之前，要求第三方停车支付系统通过基于流出的牌照付费API验证其本身。如果验证失败，那么可以提供重试机制，并且在几次尝试不成功之后，可以放弃连接。关于步骤(3)，服务器系统140可以被配置为每当车辆腾出与第三方停车支付系统相关联的目标位置时，通过基于流出的牌照付费API，将车辆停车信息上传给第三方停车支付系统。特定车辆的上传信息可以包括(例如)车牌照信息(包括车牌号和州/省信息)、由第三方停车支付系统 识别的目标位置的标识符(其需要从服务器系统140内部使用的标识符中转化)、特定车辆开始使用目标位置的实际日期/时间以及特定车辆腾出目标位置的实际日期/时间。在另一个实施例中，服务器系统140被配置为通过两个步骤与牌照付费系统整合。首先，服务器系统140使用牌照付费系统提供的API，从牌照付费系统中获得车辆支付信息(例如，支付的停车开始和结束时间以及车牌照号)。在这个阶段，服务器系统140具有生成具有违规停车细节的一系列车牌照所需要的精确信息。然而，服务器系统140不是将这个列表显示给停车场经营者，而是可以具有以下情况：现有停车支付供应商希望保持控制违规停车信息流回停车场经营者的方式。这可以通过使用由服务器系统140提供的API将违规车辆数据发送回牌照付费系统来实现。然后，牌照付费系统全面控制将这系列“违法”车辆显示给停车场经营者的方式(例如，通过由牌照付费系统供应商开发的定制软件应用程序)。这个整合方法与通过由服务器系统140提供的API与牌照付费系统整合之间的显著差异在于，这个整合方法要求的在牌照付费系统供应商部分上的开发工作最小。由于已经由服务器系统140提供的API供应了要显示给停车场经营者的所有关键信息，无需任何进一步分析，所以这个信息可以用最小的软件开发工作仅仅显示或转发给停车场经营者。这种整合方法表示在“拉入”之后“推送”的模式。188将现场操作人员团队用作在图1中显示的系统的一部分，保证考虑并且可以提供现实选择，以作为增值功能提供给预期的停车场经营者，具有两个主要原因。首先，虽然服务器系统140自主接收和处理从识别和目标摄像头中获得的图像，但是通常，现场操作人员监控所获得的图像以及在服务器系统140上执行的软件。这些现场操作人员可以审查服务器系统140的操作，并且如果需要的话，那么在异常的基础上，采取适当行动。例如，在发生出乎意料的问题时，现场操作人员可以审查与这些问题相关的图像，并且推断出服务器系统140没 有被配置为进行处理的信息。由服务器系统140支持的网络架构的一个优点在于，单个现场操作人员团队可以在多个地点监督或增加操作，与其各自的地理位置或者设施操作可以由不同的停车操作或甚至竞争者拥有这一事实无关。结果，现场操作人员选择可是一种停车场经营者可扩展的以及节省成本的方法。而且，通过使用IP多播或相似的标准TCP/IP协议，可以将视频流有效地同时传输给多个目标，从而除了由停车场经营者配备的本地现场监控以外，还可以允许在未来某天增加现场操作人员的选项。其次，根据可获得的技术，上面讨论的凭票泊车和路边计时表配置呈现重大的现实生活挑战。不仅需要具有高级变焦的摄像头，而且还具有潜在的问题，例如，特定摄影机的视角不足以适当地检测传统的路边停车计时表的到期标记，或者由于仪表板的物理三维形状以及票据本身的布置，车辆仪表板上的凭票泊车票据上的条形码可能远离任何摄影机。在服务器系统140未自动检测到一条关键的信息时，例如，车牌号、传统停车计时表上的到期标记的状态或者在凭票泊车票据上的条形码/打印信息，通过现场操作人员选择，服务器系统140可以向现场操作人员生成异常事件。这种异常事件可以触发现场操作人员采取大量具体行动，包括但不限于重绕/快进/暂停/定格由识别和/或目标摄像头捕捉的FWD&RWD具体片段，放大/缩小在捕捉的片段内的特定的相关区域，实时摇摄/倾斜/变焦摄影机，以便获得增强的图像，并且派遣现场人员，来视觉地或者通过使用移动装置150执行车辆或停车计时表的检查，以获得由服务器系统140使用的增强的图像。在一个实施例中，服务器系统140被配置为使车辆的登记持有人的邮寄地址与其车牌照号相关联，允许停车场经营者收取停车传票收入。红灯摄像头系统使用这种机构来将传票邮寄给车辆的登记持有人。与这种功能相结合，停车场经营者具有三个不同的类别。首先，如果停车经营者是已经访问DMV记录的居民/市民的一部分，那么服务器系统140仅仅需要为一系列车辆牌照号提供州/省信息以及违规停车细节 (例如，日期、时间以及位置)，以便将传票邮寄给登记持有人。其次，对于未预先建立访问DMV记录的私人停车场经营者，具有多种法律途径，来获得与车牌照号相关联的个人信息，包括姓名和地址。这些方法在每个州(以及省)之间不同。作为一个实例，在纽约州，允许私人停车场经营者使用驾驶员隐私保护法(DPPA)形式MV-15DPPA来访问这种信息，“与私人收费输送设施的操作相结合使用”、“包括为了将通知提供给使用设施的车主的目的而操作停车设施的公司”。对于一些行政辖区，姓名和地址信息可以在线发布，并且服务器系统140可以被配置为获得并且处理这种信息。在一些行政辖区中，第三方车主的姓名和地址信息可以不在线发布，但是必须通过邮件或者亲自获得。在这种行政辖区中，私人停车场经营者可以希望成批地(例如，每天、每2或3天或每周)获得姓名和地址信息。第三，对于愿意实时访问登记持有人信息的私人停车场经营者，通过互联网可获得多个私人车牌号数据库。这种方法的主要优点在于，可以直接并且自动检索姓名和地址信息，不需要手动操作。如结合图1所述，终端用户系统170可以包括车载式系统。在一个实施例中，直接来自汽车制造商的新车辆仪表板可以包括指示器图标，其与其他仪表板灯相似，例如，“检查发动机”、停车制动警告或巡航控制指示灯。在车辆130在高速公路上或者不在由服务器系统140服务的周边内部行驶时，这个指示器图标通常不照亮。在车辆130接近停车位或者路边停车场时，指示器图标可以亮起黄灯，通知终端用户由服务器系统140提供的自动停车服务的可用性。在车辆130进入目标位置(例如，停车位)内时，指示器图标变红，以通知终端用户还未支付停车费。一旦支付了停车费(无论是通过上述手机付费、路边计时表、空间付费还是其他技术)，指示器图标变绿，以表示支付了停车费。在一个实施例中，这些视觉提示可以伴有音频通知，这可以是简单的钟声或者语音通知。通过将音频信息或数据提供给车辆娱乐单元，可以执行音频输出。由于本发明能够自动操作停车支付和实施过程的很多方面，所以重要的是，给终端用户提供关于服务器系统140正在做的内容或者服务器系统140使其与 车辆130相关联的特定状态的反馈(例如，无论车辆130是否犯有违规停车)。然后，终端用户可以相应地对所提供的反馈作出反应。在高度自动化支付和实施系统内操作时，合理地期望终端用户或登记持有人不因为微小的或行政错误而受到处罚。通过简单的接口(例如，仪表板指示器图标)提供的反馈可以大幅缓解这个问题。例如，在车辆130停车时，如果指示器图标在一段时间之后保持红色，那么终端用户意识到发生了异常事件。存档的信用卡号可能到期，因此，服务器系统140不能应用停车收费。这个反馈为终端用户提供(例如)访问由服务器系统140提供的或者与服务器系统140相结合地提供的网站的机会，以查询其账户状态并且纠正错误。具有多个可能的信息源，通过这些信息源，仪表板指示器图标可以从智能传感器(下面讨论的)中获得其信息，包括嵌入式蜂窝数据或WiFi车辆连接性。对于没有工厂安装的指示器图标的较旧车辆，可以给终端用户提供具有视觉模块形式的改造工具箱，该视觉模块通过蓝牙、蜂窝数据或WiFi连接性接收信息。在一个实施例中，指示器图标特征通过车辆线束从第三方车载式子系统中接收GPS位置数据。GPS数据允许指示器图标特征确定车辆130目前是否在支付的停车区域内。与车辆仪表板图标相似，智能传感器可以设计到直接来自工厂的新车内。使用与ZigBeeIEEE802.15.4标准相似的技术，可以在车辆之中并且在车辆与停车设备之间，产生低成本、低功率以及短距离无线网状网络。每个车辆都是个节点，并且通过形成网状网络，通过中间节点中继数据，节点可以与远端点通信。每个智能传感器包含唯一标识符，以便车牌信息不再关键。在一个实施例中，智能传感器可以被配置为通过蜂窝数据连接与服务器系统140通信，和/或提供手机付费功能，据此，可以通过智能传感器进行使用目标位置的支付。许多应用程序可能引入这种智能传感器。例如，智能传感器可以包括GPS接收器或者可以与车载GPS通信，以确定车辆130的现有位置并且将现有位置报告给服务器系统140。通过一些GPS技术，例如，辅助GPS，通过GPS确定 的位置可以具有足够的精密度与准确度，以确定车辆利用特定的目标位置。这些传感器还可以与停车计时表通信，并且本质上，报告车辆的存在以及停车的时间长度。这个停车信息可以通过网状网络中继给远程装置/网络，以便停车设备不需要位于车辆附近内。对于装有智能传感器的车辆，不需要使用识别和目标摄像头，这是因为嵌入式智能传感器已经将车辆的唯一身份提供给服务器系统140。在一个实施例中，车辆装有近场通信(NFC)装置，例如，RFID芯片。例如，这种通信装置可以包含在反射镜悬挂物内。在另一个实施例中，RFID芯片可以嵌入由凭票泊车装置提供的票据内。通过从近场通信装置中获得车辆标识，服务器系统140可以不要求使用由识别摄像头捕捉的图像(例如，包括车牌信息的图像)，和/或可用于验证从与观察的车辆对应的NFC装置中接收的信息。在一个实施例中，智能传感器可以感测附近其他装置的状态(例如但不限于它们是否移动、停车以及停车的持续时间)，并且将该状态报告给服务器系统140。最终结果在于，服务器系统140知晓几乎所有安装智能传感器的车辆停车的地方以及时长。通过使这个信息与第三方系统或成套平台的停车支付信息相结合，能够确定未支付停车或停车到期的车辆的身份，并且将违规停车传票邮寄给登记持有人或者甚至当场收取停车罚款(例如，通过收取存档的信用卡)。在一个实施例中，目标摄像头可以具有激光状态通知。与在商场和零售商店看到的激光标识装置相似，激光状态通知特征发出无害的红色闪烁光，包围停放的车辆，以便在返回时，通知终端用户停车费未支付或者到期。这类似于返回车辆并且在传统的手动停车执法模型之下，看到违规停车罚单夹在雨刷之下。由于目标摄像头通常位于车辆的某个高度，所以包括的激光状态通知模块在目标位置之下具有鸟瞰图，以在车辆和目标位置上促进发光激光通知。在一个实施例中，激光状态通知特征代替了邮寄纸质违规停车罚单的需要。一旦终端用户接收到违规停车的激光通知，那么就可以预期终端用户通过多个介质来支付停车罚单，包括但不限于在线网站或手机付费。而且，激光状态通知可以由目标摄像头捕捉，以稍后提供违规停车的证据和通知。在一个实施例中，动态实时单个停车位预留是在线/手机/智能电话停车位预留系统能够具有的功能，并且可以通过激光状态通知功能进一步增强。虽然目前一些供应商提供停车位预留功能，但是该功能限于在停车位大概附近的车位预留(例如，在停车场上的某个地方)，这是因为没有实际的方法来通过自动的方式物理上预留单个特定的停车位。此外，预留的车位通常保持长时间开放，这是因为在预留车位的驾驶员停车并且随后开走之后，没有实际的方法知道预留的停车位再次可用的时间。相反，动态实时单个停车位预留功能允许终端用户在规定的时间段(例如，目标位置可以预留，以在未来的某天使用)准确地找出其需要的精确停车位(例如，在圣诞购物季最接近商场的车位)。一旦预留停车位，激光通知就可以在停车位上发光，以表示目标位置预留(例如，提供红色，作为对其他驾驶员的警告)。另一辆车在预留周期使用目标位置，会造成违规停车。通过提供分层/高价停车位以及停车位的提前预约，这能够允许停车场经营者增加收入。在一个实施例中，停车场经营者可以指定特定的目标位置，作为仅仅限于供进行预订了的车辆使用。在这个实施例中，服务器系统140可以确定在规定的时间可用的预订目标位置的数量，并且根据未预订的目标位置依然可用的数量，确定保留价格。在一个实施例中，服务器系统140可以被配置为允许买家提交使用预订目标位置的竞争性出价。在一个实施例中，手机付费功能可以直接在成套平台上或者通过与第三方供应商的伙伴关系来提供。最终结果是终端用户可以通过呼叫特定的IVR电话线路来支付停车费，输入目标位置编号或车牌号以及停车的持续时间。在另一个实施例中，在线支付是沿着相同主题的变体，以支持在线支付停车，通常通过经由启用网络的智能电话可访问的网站。在一个实施例中，可以包括“推送”技术功能，其中，一旦终端用户停放车辆130，终端用户就接收文本消息或其他通知，提示收取特定的停车费的肯定回复，直到车辆130离开目标位置。服务器系统140通过目标摄像头识别车辆130，并且进一步确定车辆130与预先登记的终端用户相关联，记录了信用 卡或其他账单信息以及手机号码或其他联系信息。一旦服务器系统140通过目标摄像头确定车辆130停放在目标位置内，服务器系统140就开始“推送”序列，来积极地通知并且使驾驶员支付或确认支付。通过简化支付流程，实现停车收益的提高。在很多传统的停车计时表系统中，如果终端用户支付的时间比终端用户实际使用的时间更多，那么剩余时间依然在计时表上，以供下一个终端用户使用。在所公开的主题的实施方式中，由于目标摄像头125允许服务器系统140精确地确定车辆离开目标位置的时间，所以任何“剩余的”支付的停车时间可以重设为0。一个例外情况是传统的路边计时表，这是因为这些计时表通常没有任何通信能力或智能来在时间到期之前激活到期标记。服务器系统140可以被配置为提供推送技术软件元件，在支付停车费时，该元件增强了用户体验。推送技术支持以下功能，例如：(1)通过文本消息启动支付序列；(2)允许预先登记的用户拍摄其车牌照的照片，然后，通过(例如)电子邮件或文本消息将照片提供给服务器系统140；(3)允许未登记的用户拍摄其车牌照的照片，然后，通过(例如)电子邮件或文本消息将照片提供给服务器系统140；以及(4)在基于订阅的模式下，一旦没有获得停车费用，就允许驾驶员登记。推送技术元件与车辆标识符检测逻辑、车辆检测逻辑、数据库141以及支付网关相互作用。关于条目(1)，根据开始使用目标位置(例如，停车位)的车辆的车辆标识符，推送技术元件给向服务器系统140登记的手机号码推送文本消息，表示开始使用目标位置。在驾驶员通过回复“是”来同意文本消息时，与登记账户相关联的信用卡随后可以支付合适的使用费，例如但不限于使用目标位置的定额停车费。关于条目(2)，向服务器系统140预先登记的驾驶员可以拍摄其车牌照的照片，然后，通过电子邮件或文本消息将照片发送给服务器系统140。然后，与预先登记的用户的登记账户相关联的信用卡可以支付使用费。关于条目(3)，对于具有未向服务器系统140登记车牌照的车辆，驾驶员可以拍摄其车牌照的照片，然后，通过电子邮件/文本消息将照片发送给服务器系统140。在移动电话服务提供商支持并且提供对这种计费 功能的访问的情况下，可以将使用费加入用户每月的移动装置账单中。关于条目(4)，一旦使用登记的信用卡自动支付所有使用费(或者至少所有停车费)，驾驶员就可以签署。推送技术软件元件还可以被配置为如果服务器系统140确定不适当地使用目标位置，例如，在“非停车”区域内停放车辆，那么将文本消息自动发送给用户。服务器系统140可以被配置为提供违规停车预先处理逻辑软件元件，该元件检查最新确定为违规的目标位置使用的所有发生情况并且将其分配给在系统配置内规定的相应目标，例如，下面讨论的牌照查找模块或牌照转发模块。违规停车预先处理逻辑软件元件与数据库141、系统配置实用程序以及第三方API相互作用。违规停车预先处理逻辑软件元件可以被配置为：(1)使由包含在服务器系统140内的其他软件处理所识别的违规排队；(2)检查在队列中的下一次违规；(3)通过验证经由系统配置实用程序结合目标位置建立的规则并且检测车辆使用目标位置，来证实目标位置使用违规；(4)将违规分配给牌照处理逻辑；以及(5)检查任何其他排队违规或等待识别稍后的违规。服务器系统140可以被配置为确定车辆是否具有来自识别图像的到期标记。虽然通过典型的距离和车速，并且在车牌照上具有小尺寸的典型到期日期指示符，通常不能确定车辆是否单独具有来自识别图像的到期标记，但是可以使用固定的识别摄像头120来捕捉识别图像。利用放大静止车辆的车牌照的具有PTZ功能的摄像头，通过识别摄像头或目标摄像头，能够放大车牌照，以获得足够的细节来确定车辆是否单独具有来自所获得的图像的到期标记。在一个实施例中，识别图像可以通过移动或手持式摄像头捕捉，包括(例如)包含在智能电话或移动装置150内的摄像头。从这种来源中获得的识别图像通常具有足够的细节来确定车辆是否单独具有识别图像的到期标记。在一个实施例中，并非单独使用图像来确定标记是否到期，服务器系统140可以被配置为通过API向市级数据库查询，确定特定车牌照的车辆登记是否到期。服务器系统140可以被配置为如果确定车辆具有到期标记，那么将车辆报告给市政当局。服务器系统140可以被配置为提供车牌照处理逻辑软件元件，该元件采取 识别的目标位置使用违规，例如，由违规停车预先处理逻辑元件确定的违规，并且将该违规转换成可诉条目，用于涉及目标位置使用违规的车辆的登记持有人(RO)/用户或者用于负责目标位置的停车场经营者。例如，可诉条目可以具有自动邮寄给登记持有人的违规停车传票或者在停车操作办公室的屏幕上显示的车牌照号的形式。车牌照处理逻辑软件元件与违规停车预先处理逻辑软件元件、系统配置实用程序以及数据库141相互作用。违规停车预先处理逻辑元件可以被配置为检查通过系统配置实用程序结合目标位置规定的一个或多个商业规则，以确定合适的可诉条目。例如，如果商业规则规定车牌照查找，那么也可以规定特定类型的车牌照查找，例如，通过由市政当局提供的API或者由私人企业提供的API。然后，按照规定，执行车牌照查找。而且，商业规则可以识别子选项，例如，通过API将违规停车传票邮寄给登记持有人，或者仅仅给停车场经营者提供登记持有人的邮寄地址和违规的任何其他相关联的信息。在另一个实例中，如果商业规则规定转发车牌照信息，那么车牌照处理逻辑元件检查，以查看特定类型的所规定的车牌照信息转发，并据此转发车牌照信息。为了使用车牌照查找API选项，用于从车牌照车辆标识符中识别登记持有人的邮寄地址的目的，必须具有车牌照数据库(例如，由私人企业提供的数据库)并且可以用搜索属于车牌照的特定州/省的车牌照。而且，这种数据库的使用在具商业利益的这种查找中涉及的任何费用方面必须合理。如果以上任一个条件没有实现，那么替换的选择可以包括将讨论中的车牌照提供给市政机构，市政机构通常通过当地警察部门或以其他方式访问车牌照记录。车牌照处理逻辑软件元件可以包括车牌照查找和追踪子模块。车牌照查找和追踪子模块可以被配置为API调用车牌照数据库，以检索车辆的登记持有人的邮寄地址。这种数据库的实例包括由纽约州机动车辆管理局提供的基于HTTP的拨号搜索账户API、由美国机动车辆管理员协会(AAMVA)或其他保险公司提供的数据库服务、以及在线公共记录集合，例如，PublicData.com(虽然很多这种集合不如政府或商业管理的数据库可靠，因此可能需要额外的努力来确保信息有效并且准确)。而且，车牌照查找和追踪子模块可以被配置为将停车传票自动邮寄给与错误使用目标位置的车辆相关联的登记持有人。例如，邮寄处理可以通过API调用自动化为打印/邮寄服务，例如但不限于L-Mail.com。在一个实施例中，车牌照查找和追踪子模块可以被配置为产生、保持以及检索在数据库141内的记录，以查看规定的车牌标识符(例如，车牌)是否与目标位置在规定的时间段内的先前错误使用相关联(例如，通过系统配置实用程序，可配置)。如果相关联的话，那么车牌照查找和追踪子模块可以假设先前获得的地址依然有效并且准确，跳过API调用，并且在系统中使用先前获得的邮寄地址来邮寄传票，以便降低与API调用相关联的操作费用。如果在规定的天数(例如，通过系统配置实用程序，也可配置的实际持续时间)之后未支付违规停车传票，或者由于无法投递而退回传票，那么随后可以API调用，以获得当前地址。在一个实施例中，违规停车，例如但不限于在支付的停车到期或者车辆未支付而停车，服务器系统140可以被配置为通知一个或多个执法人员目标位置的位置，例如，经纬度或大约街道地址。然后，执法人员可以走向违规车辆，并且现场发出传票。在一个实施例中，服务器系统140可以被配置为识别和/或定位最适合于处理特定违规车辆的个别执法人员。进行这个识别的因素可以包括(例如)与违规车辆相距的距离或执法人员的工作量或者是否拖曳违规车辆(例如，在违规车辆必须立即移走的情况下)。在一个实施例中，例如，在具有太少的执法人员或者特定的执法人员要处理多个违法车辆的情况下，违规车辆需要排队。在一个实施例中，可以通知多个执法人员附近具有违规车辆，并且各执法人员可以接受处理特定的违规车辆。服务器系统140还可以被配置为跟踪执法人员的行为，这可以与执法人员的奖励或配额制度一起使用。在一个实施例中，执法人员可以配有移动装置150，并且移动装置150可以被配置为给违规车辆预先打印传票，以减少将传票传递给车辆所需要的时间量。服务器系统140可以被配置为提供动态可变费率停车费。在一个实施例中，服务器系统140可以给目标位置记录不同的停车费，例如，这些停车费随着每 天的时间和/或每周的日期改变。如果车辆在应用第一费率和第二费率的时间段内占据目标位置，那么服务器系统140可以被配置为根据第一费率和第二费率确定使用目标位置的总费用，其中，从使用目标位置开始应用第一费率，直到应用第二费率，而在车辆占据目标位置的剩余时间，应用第二费率。在一个实施例中，服务器系统140可以被配置为确定在规定的区域内可用目标位置可以容纳的车辆数，并且使停车的费用或费率基于所确定的车辆数。例如，随着服务器系统140确定这个数量减少(例如，由于具有更少的剩余目标位置)，可以对开始利用很少的剩余位置的车辆应用更高的费率。服务器系统140可以被配置为允许停车提供商通过API或配置实用程序规定特定的事件，用于特定时间的指定停车费率或固定费用要适用于规定的目标位置。例如，如果在与停车设施性关联的或者在停车设施附近的地点从7到11PM举行音乐会，那么停车设施可以向在那天晚上4PM之后停放的车辆征收固定$10的费用。服务器系统140可以被配置为提供非罚款功能，其中，驾驶员可以离开停放在目标位置的车辆随便多久，并且根据为目标位置建立的规则(例如但不限于每小时或每天固定费率的费用)，向信用卡或其他账户收账。在一个实施例中，文本消息或电子邮件可以推送或者发送给驾驶员，表示非罚款功能可用于目标位置，并且允许驾驶员选择使用非罚款功能，例如，通过回复消息，例如，“是”或“非罚款”。在一个实施例中，服务器系统140可以被配置为总体上使非罚款功能可用于在特定区域内的或者在由服务器系统140跟踪的整个目标位置中所有不限制的目标位置。然而，服务器系统140可以被配置为不将非罚款功能提供给受限的目标位置，例如，受到3-6PM“非停车”高峰时间限制的目标位置。在一个实施例中，服务器系统140能够根据车辆的3D轮廓进行轮廓分析。例如，这种轮廓分析能够概略地将车辆的轮廓划为属于以下类别：例如但不限于运动型多用途车(SUV)、面包车、轿车、轿跑车或摩托车。此外，车辆可以分类为具有明色或暗色。车辆轮廓分析可以服务非停车应用程序，例如但不限于帮助警察在某个范围内跟踪被盗车辆、安珀警戒、国土安全需要。在一个实 施例中，车辆轮廓分析可以用于提供额外的车辆特征，用于在跟踪车辆时进行从一个跟踪摄像头到另一个跟踪摄像头的比较。在一个实施例中，车辆轮廓分析可以给自动停车传票邮寄过程提供车辆身份的确认的额外层。在一个实施例中，给服务器系统140提供手动3D车辆轮廓。例如，ChevroletImpala的一个手动3D车辆轮廓可以描述引擎盖的高度与乘客舱的高度与行李箱的高度的比率1:2:1。在一个实施例中，可以与驱动的光束偏转镜整合的激光传输器可以被配置为在一个或多个目标位置上使激光光束发亮。在一个实施例中，激光光束可以在安装在目标位置上或周围的反光镜上发光，以将返回信号提供给与激光收发器相关联的接收器。在车辆占据由激光光束照亮的目标位置时，通过中断激光光束或返回信号，检测车辆的存在。响应于这个检测，服务器系统140可以被配置为通过附近的摄像头获得目标图像和/或标识符图像。在一个实施例中，服务器系统140可以被配置为除了涉及车辆识别的上述用途以外，还使用识别摄像头，作为“红灯摄像头”，用于检测事件，其中，车辆通过由交通灯控制的十字路口错误地继续进行。例如，在交通灯从黄色变成红色时，可以识别通过稍后的黄灯或红灯错误地继续进行的车辆，并且捕捉车牌号，以便服务器系统140被配置为将成像摄像头同时用于这两个目的。或者/此外，服务器系统140可以被配置为使用识别摄像头来检测“阻塞方框(blockthebox)”行车违规，其中，在车辆行驶方向的红灯期间，车辆依然在十字路口内，这可以造成交通堵塞高流量的情况。在一个实施例中，服务器系统140可以被配置为给第三方提供实时车辆跟踪服务，例如但不限于收回公司(用于定位未偿还贷款支付的车辆)、法律实施、国土安全。服务器系统140可以提供API，通过该API，这种第三方实体可以通过(例如)车辆标识符(例如，车牌照)登记相关车辆。如果服务器系统140通过车辆标识符确定具有车辆，那么可以通知登记方。可以结合车辆的初始检测和/或在确定车辆停止时，提供通知。在一个实施例中，登记车辆的运动的记录可以由服务器系统140保持，并且例如，通过基于地图的网络接口可获得， 该接口可以被配置为实时显示更新的信息。API还可以允许第三方指定相关区域，服务器系统140被配置为对确定进入了相关区域内的任何车辆进行识别和跟踪。服务器系统140还可以被配置为提供由跟踪摄像头获得的登记车辆的图像。在一个实施例中，任何存档的跟踪信息(例如，目标位置的过去使用)也可以用于随着时间重构个人的位置(假设个人与车辆连接)。在一个实施例中，服务器系统140可以被配置为获得车辆图像，包括驾驶员脸部的图像，并且可以进一步被配置为执行脸部识别技术，以确认驾驶员的脸部特征与嫌疑人对应。在一个实施例中，服务器系统140可以被配置为确定和提供交通量计数信息，例如，确定横穿道路的规定部分的车辆的数量。这种信息可以用于以下目的：包括但不限于响应于目前观察的交通量计数，动态控制交通系统(例如，交通灯)，并且用于根据随着时间观察的交通量计数，确定构造要求。可以在时间和/或日期和/或确定的车辆特征的基础上，包括和/或过滤交通量计数信息，包括但不限于行驶方向和车辆大小或类型(例如，SUV、卡车、汽车或摩托车)。此外，服务器系统140可以确定进和/或出一部分道路的车辆数量，例如，根据每辆车离开十字路口的方向，在离开道路的往东部分时，往北或往南的车辆的数量。在一个实施例中，服务器系统140可以被配置为用于按照类型控制访问车辆和/或对车辆征税，例如，评估大型卡车使用特定的道路的费用。图5是示出了计算机系统500的方框图，在该系统上可以实现本发明的方面。计算机系统500包括总线502或用于传送信息的其他通信机制，以及与总线502耦合的、用于处理信息的处理器504。计算机系统500还包括与总线502耦合的主存储器506，例如，随机存取存储器(RAM)或其他动态存储装置，用于存储由处理器504执行的信息和指令。主存储器506还可以用于在执行由处理器504执行的指令时，存储临时变量或其他中间信息。计算机系统500进一步包括只读存储器(ROM)508或与总线502耦合的其他静态存储装置，用于存储用于处理器504的静态信息和指令。提供存储装置510(例如，磁盘或光盘)，并且耦合至总线502，用于存储信息和指令。计算机系统500可以通过总线502耦合至显示器512，例如，阴极射线管 (CRT)或液晶显示器(LCD)，用于向计算机用户显示信息。输入装置514(包括字母数字键和其他键)耦合至总线502，用于将信息和命令选择传送给处理器504。另一种类型的用户输入装置是光标控件516，例如，鼠标、轨迹球或光标方向键，用于将方向信息和命令选择传送给处理器504并且用于控制显示器512上光标的移动。这个输入装置通常在两个轴上具有两个自由度，即，第一轴(例如，x)和第二轴(例如，y)，其允许该装置规定在平面内的位置。另一种类型的输入装置是触摸屏，该触摸屏通常使显示器512与在显示器512上记录触摸的硬件相结合。本发明涉及一个或多个诸如计算机系统500的计算机系统的使用，其共同被配置为和/或编程为执行实现在本文中描述的技术。根据本发明的一个实施例，响应于处理器504执行包含在主存储器506内的一个或多个指令的一个或多个序列，计算机系统500执行那些技术。这种指令可以从另一个机器可读介质(例如，存储装置510)中读入主存储器506内。包含在主存储器506内的指令序列的执行，使得处理器504执行在本文中描述的过程步骤。在替换的实施例中，硬接线电路可以代替或者与软件指令执行一起使用，以实现本发明。因此，本发明的实施例不限于硬件电路和软件的任何具体组合。在本文中使用的术语“机器可读介质”表示参与提供促使机器通过具体的方式操作的数据的任何介质。在使用计算机系统500实现的实施例中，各种机器可读介质(例如)涉及将指令提供给处理器504，用于执行。这种介质可以采用多种形式，包括但不限于非易失性介质、易失性介质以及传输介质。非易失性介质包括(例如)光盘或磁盘，例如，存储装置510。易失性介质包括动态存储器，例如，主存储器506。传输介质包括同轴电缆、铜线以及光纤，包括包含总线502的电线。传输介质还可以采用声波或光波的形式，例如，在无线电波或红外线数据通信期间生成的声波或光波。所有这种介质必须是有形和/或永久的，以便将指令读入机器内的物理机制能够检测由介质携带的指令。常见形式的机器可读介质包括(例如)软盘、软磁盘、硬盘、磁带或任何其他磁性介质、CD-ROM、任何其他光学介质、打孔卡、纸带、具有孔模式的 任何其他物理介质、RAM、PROM、EPROM、FLASH-EPROM、任何其他存储芯片或匣、在后文中描述的载波、或者计算机可读取的任何其他介质。各种形式的机器可读介质可以涉及将一个或多个指令的一个或多个序列传送给处理器504，用于执行。例如，最初可以在磁盘或远程计算机上携带指令。远程计算机可以将指令载入其动态存储器内并且通过使用调制解调器的电话线发送指令。位于计算机系统500本地的调制解调器可以在电话线上接收数据，并且使用红外线发射机来将数据转换成红外线信号。红外线检测器可以接收在红外线信号内携带的数据，并且合适的电路可以将数据放在总线502上。总线502将数据传送给主存储器506，从该主存储器中，处理器504检索并且执行指令。在由处理器504执行之前或之后，由主存储器506接收的指令可以可选地存储在存储装置510上。计算机系统500还包括耦合至总线502的通信接口518。通信接口518提供耦合到与本地网络522连接的网络链路520的双向数据通信。例如，通信接口518可以是综合业务数字网(ISDN)卡或调制解调器，以将数据通信连接提供给相应类型的电话线。再如，通信接口518可以是局域网(LAN)卡，以将数据通信连接提供给兼容的LAN。还可以实现无线链路。在任何这种实现方式中，通信接口518发送和接收携带表示各种类型信息的数字数据流的电气、电磁或光学信号。网络链路520通常提供通过一个或多个网络与其他数据装置的数据通信。例如，网络链路520可以提供通过本地网络522与主机计算机524的连接或者与由互联网服务提供商(ISP)526运营的数据设备的连接。ISP526反过来通过现在俗称为“互联网”528的世界范围的分组数据通信网络提供数据通信服务。本地网络522和互联网528均使用携带数字数据流的电气、电磁或光学信号。通过各种网络的信号以及在网络链路520上并且通过通信接口218的信号将数字数据传送给计算机系统500并且从计算机系统中传送数据，是传输信息的载波的示例性形式。计算机系统500可以通过网络、网络链路520以及通信接口518发送消息 和接收数据，包括程序代码。在互联网实例中，服务器530可能通过互联网528、ISP526、本地网络522以及通信接口518传输应用程序的请求代码。在存储装置510和/或非易失性存储器内接收和/或存储时，所接收的代码可以由处理器204执行，用于稍后执行。通过这种方式，计算机系统500可以获得具有载波形式的应用程序代码。在以上说明书中，参照可以随实现方式变化的多种具体细节，描述了本发明的实施例。因此，本发明以及本发明的申请人意图的唯一独有的指标是从本申请中发布的权利要求的集合，具有发布这种权利要求的具体形式，包括任何后续校正。在本文中明确提出的用于包含在这种权利要求内的术语的任何定义应控制在权利要求中使用的这种术语的意义。因此，在权利要求中未明确叙述的任何限制、部件、性能、特征、优点或属性都不应以任何方式限制这种权利要求的范围。因此，说明书和附图应被视为具有说明性而非限制性的意义。